A new capability (KVM_CAP_ARM_MTE) identifies that the kernel supports
granting a guest access to the tags, and provides a mechanism for the
VMM to enable it.
A new ioctl (KVM_ARM_MTE_COPY_TAGS) provides a simple way for a VMM to
access the tags of a guest without having to maintain a PROT_MTE mapping
in userspace. The above capability gates access to the ioctl.
Signed-off-by: Steven Price <steven.price@arm.com>
---
Documentation/virt/kvm/api.rst | 53 ++++++++++++++++++++++++++++++++++
1 file changed, 53 insertions(+)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 22d077562149..a31661b870ba 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -5034,6 +5034,40 @@ see KVM_XEN_VCPU_SET_ATTR above.
The KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST type may not be used
with the KVM_XEN_VCPU_GET_ATTR ioctl.
+4.130 KVM_ARM_MTE_COPY_TAGS
+---------------------------
+
+:Capability: KVM_CAP_ARM_MTE
+:Architectures: arm64
+:Type: vm ioctl
+:Parameters: struct kvm_arm_copy_mte_tags
+:Returns: 0 on success, < 0 on error
+
+::
+
+ struct kvm_arm_copy_mte_tags {
+ __u64 guest_ipa;
+ __u64 length;
+ union {
+ void __user *addr;
+ __u64 padding;
+ };
+ __u64 flags;
+ __u64 reserved[2];
+ };
+
+Copies Memory Tagging Extension (MTE) tags to/from guest tag memory. The
+``guest_ipa`` and ``length`` fields must be ``PAGE_SIZE`` aligned. The ``addr``
+fieldmust point to a buffer which the tags will be copied to or from.
+
+``flags`` specifies the direction of copy, either ``KVM_ARM_TAGS_TO_GUEST`` or
+``KVM_ARM_TAGS_FROM_GUEST``.
+
+The size of the buffer to store the tags is ``(length / MTE_GRANULE_SIZE)``
+bytes (i.e. 1/16th of the corresponding size). Each byte contains a single tag
+value. This matches the format of ``PTRACE_PEEKMTETAGS`` and
+``PTRACE_POKEMTETAGS``.
+
5. The kvm_run structure
========================
@@ -6362,6 +6396,25 @@ default.
See Documentation/x86/sgx/2.Kernel-internals.rst for more details.
+7.26 KVM_CAP_ARM_MTE
+--------------------
+
+:Architectures: arm64
+:Parameters: none
+
+This capability indicates that KVM (and the hardware) supports exposing the
+Memory Tagging Extensions (MTE) to the guest. It must also be enabled by the
+VMM before the guest will be granted access.
+
+When enabled the guest is able to access tags associated with any memory given
+to the guest. KVM will ensure that the pages are flagged ``PG_mte_tagged`` so
+that the tags are maintained during swap or hibernation of the host; however
+the VMM needs to manually save/restore the tags as appropriate if the VM is
+migrated.
+
+When enabled the VMM may make use of the ``KVM_ARM_MTE_COPY_TAGS`` ioctl to
+perform a bulk copy of tags to/from the guest.
+
8. Other capabilities.
======================
--
2.20.1
On Mon, 17 May 2021 13:32:39 +0100,
Steven Price <steven.price@arm.com> wrote:
>
> A new capability (KVM_CAP_ARM_MTE) identifies that the kernel supports
> granting a guest access to the tags, and provides a mechanism for the
> VMM to enable it.
>
> A new ioctl (KVM_ARM_MTE_COPY_TAGS) provides a simple way for a VMM to
> access the tags of a guest without having to maintain a PROT_MTE mapping
> in userspace. The above capability gates access to the ioctl.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> Documentation/virt/kvm/api.rst | 53 ++++++++++++++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 22d077562149..a31661b870ba 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -5034,6 +5034,40 @@ see KVM_XEN_VCPU_SET_ATTR above.
> The KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST type may not be used
> with the KVM_XEN_VCPU_GET_ATTR ioctl.
>
> +4.130 KVM_ARM_MTE_COPY_TAGS
> +---------------------------
> +
> +:Capability: KVM_CAP_ARM_MTE
> +:Architectures: arm64
> +:Type: vm ioctl
> +:Parameters: struct kvm_arm_copy_mte_tags
> +:Returns: 0 on success, < 0 on error
> +
> +::
> +
> + struct kvm_arm_copy_mte_tags {
> + __u64 guest_ipa;
> + __u64 length;
> + union {
> + void __user *addr;
> + __u64 padding;
> + };
> + __u64 flags;
> + __u64 reserved[2];
> + };
This doesn't exactly match the structure in the previous patch :-(.
> +
> +Copies Memory Tagging Extension (MTE) tags to/from guest tag memory. The
> +``guest_ipa`` and ``length`` fields must be ``PAGE_SIZE`` aligned. The ``addr``
> +fieldmust point to a buffer which the tags will be copied to or from.
> +
> +``flags`` specifies the direction of copy, either ``KVM_ARM_TAGS_TO_GUEST`` or
> +``KVM_ARM_TAGS_FROM_GUEST``.
> +
> +The size of the buffer to store the tags is ``(length / MTE_GRANULE_SIZE)``
Should we add a UAPI definition for MTE_GRANULE_SIZE?
> +bytes (i.e. 1/16th of the corresponding size). Each byte contains a single tag
> +value. This matches the format of ``PTRACE_PEEKMTETAGS`` and
> +``PTRACE_POKEMTETAGS``.
> +
> 5. The kvm_run structure
> ========================
>
> @@ -6362,6 +6396,25 @@ default.
>
> See Documentation/x86/sgx/2.Kernel-internals.rst for more details.
>
> +7.26 KVM_CAP_ARM_MTE
> +--------------------
> +
> +:Architectures: arm64
> +:Parameters: none
> +
> +This capability indicates that KVM (and the hardware) supports exposing the
> +Memory Tagging Extensions (MTE) to the guest. It must also be enabled by the
> +VMM before the guest will be granted access.
> +
> +When enabled the guest is able to access tags associated with any memory given
> +to the guest. KVM will ensure that the pages are flagged ``PG_mte_tagged`` so
> +that the tags are maintained during swap or hibernation of the host; however
> +the VMM needs to manually save/restore the tags as appropriate if the VM is
> +migrated.
> +
> +When enabled the VMM may make use of the ``KVM_ARM_MTE_COPY_TAGS`` ioctl to
> +perform a bulk copy of tags to/from the guest.
> +
Missing limitation to AArch64 guests.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
On 17/05/2021 19:09, Marc Zyngier wrote:
> On Mon, 17 May 2021 13:32:39 +0100,
> Steven Price <steven.price@arm.com> wrote:
>>
>> A new capability (KVM_CAP_ARM_MTE) identifies that the kernel supports
>> granting a guest access to the tags, and provides a mechanism for the
>> VMM to enable it.
>>
>> A new ioctl (KVM_ARM_MTE_COPY_TAGS) provides a simple way for a VMM to
>> access the tags of a guest without having to maintain a PROT_MTE mapping
>> in userspace. The above capability gates access to the ioctl.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> Documentation/virt/kvm/api.rst | 53 ++++++++++++++++++++++++++++++++++
>> 1 file changed, 53 insertions(+)
>>
>> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
>> index 22d077562149..a31661b870ba 100644
>> --- a/Documentation/virt/kvm/api.rst
>> +++ b/Documentation/virt/kvm/api.rst
>> @@ -5034,6 +5034,40 @@ see KVM_XEN_VCPU_SET_ATTR above.
>> The KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST type may not be used
>> with the KVM_XEN_VCPU_GET_ATTR ioctl.
>>
>> +4.130 KVM_ARM_MTE_COPY_TAGS
>> +---------------------------
>> +
>> +:Capability: KVM_CAP_ARM_MTE
>> +:Architectures: arm64
>> +:Type: vm ioctl
>> +:Parameters: struct kvm_arm_copy_mte_tags
>> +:Returns: 0 on success, < 0 on error
>> +
>> +::
>> +
>> + struct kvm_arm_copy_mte_tags {
>> + __u64 guest_ipa;
>> + __u64 length;
>> + union {
>> + void __user *addr;
>> + __u64 padding;
>> + };
>> + __u64 flags;
>> + __u64 reserved[2];
>> + };
>
> This doesn't exactly match the structure in the previous patch :-(.
:( I knew there was a reason I didn't include it in the documentation
for the first 9 versions... I'll fix this up, thanks for spotting it.
>> +
>> +Copies Memory Tagging Extension (MTE) tags to/from guest tag memory. The
>> +``guest_ipa`` and ``length`` fields must be ``PAGE_SIZE`` aligned. The ``addr``
>> +fieldmust point to a buffer which the tags will be copied to or from.
>> +
>> +``flags`` specifies the direction of copy, either ``KVM_ARM_TAGS_TO_GUEST`` or
>> +``KVM_ARM_TAGS_FROM_GUEST``.
>> +
>> +The size of the buffer to store the tags is ``(length / MTE_GRANULE_SIZE)``
>
> Should we add a UAPI definition for MTE_GRANULE_SIZE?
I wasn't sure whether to export this or not. The ioctl is based around
the existing ptrace interface (PTRACE_{PEEK,POKE}MTETAGS) which doesn't
expose a UAPI definition. Admittedly the documentation there also just
says "16-byte granule" rather than MTE_GRANULE_SIZE.
So I'll just remove the reference to MTE_GRANULE_SIZE in the
documentation unless you feel that we should have a UAPI definition.
>> +bytes (i.e. 1/16th of the corresponding size). Each byte contains a single tag
>> +value. This matches the format of ``PTRACE_PEEKMTETAGS`` and
>> +``PTRACE_POKEMTETAGS``.
>> +
>> 5. The kvm_run structure
>> ========================
>>
>> @@ -6362,6 +6396,25 @@ default.
>>
>> See Documentation/x86/sgx/2.Kernel-internals.rst for more details.
>>
>> +7.26 KVM_CAP_ARM_MTE
>> +--------------------
>> +
>> +:Architectures: arm64
>> +:Parameters: none
>> +
>> +This capability indicates that KVM (and the hardware) supports exposing the
>> +Memory Tagging Extensions (MTE) to the guest. It must also be enabled by the
>> +VMM before the guest will be granted access.
>> +
>> +When enabled the guest is able to access tags associated with any memory given
>> +to the guest. KVM will ensure that the pages are flagged ``PG_mte_tagged`` so
>> +that the tags are maintained during swap or hibernation of the host; however
>> +the VMM needs to manually save/restore the tags as appropriate if the VM is
>> +migrated.
>> +
>> +When enabled the VMM may make use of the ``KVM_ARM_MTE_COPY_TAGS`` ioctl to
>> +perform a bulk copy of tags to/from the guest.
>> +
>
> Missing limitation to AArch64 guests.
As mentioned previously it's not technically limited to AArch64, but
I'll expand this to make it clear that MTE isn't usable from a AArch32 VCPU.
Thanks,
Steve
On Wed, 19 May 2021 15:09:23 +0100,
Steven Price <steven.price@arm.com> wrote:
>
> On 17/05/2021 19:09, Marc Zyngier wrote:
> > On Mon, 17 May 2021 13:32:39 +0100,
> > Steven Price <steven.price@arm.com> wrote:
> >>
> >> A new capability (KVM_CAP_ARM_MTE) identifies that the kernel supports
> >> granting a guest access to the tags, and provides a mechanism for the
> >> VMM to enable it.
> >>
> >> A new ioctl (KVM_ARM_MTE_COPY_TAGS) provides a simple way for a VMM to
> >> access the tags of a guest without having to maintain a PROT_MTE mapping
> >> in userspace. The above capability gates access to the ioctl.
> >>
> >> Signed-off-by: Steven Price <steven.price@arm.com>
> >> ---
> >> Documentation/virt/kvm/api.rst | 53 ++++++++++++++++++++++++++++++++++
> >> 1 file changed, 53 insertions(+)
> >>
> >> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> >> index 22d077562149..a31661b870ba 100644
> >> --- a/Documentation/virt/kvm/api.rst
> >> +++ b/Documentation/virt/kvm/api.rst
> >> @@ -5034,6 +5034,40 @@ see KVM_XEN_VCPU_SET_ATTR above.
> >> The KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST type may not be used
> >> with the KVM_XEN_VCPU_GET_ATTR ioctl.
> >>
> >> +4.130 KVM_ARM_MTE_COPY_TAGS
> >> +---------------------------
> >> +
> >> +:Capability: KVM_CAP_ARM_MTE
> >> +:Architectures: arm64
> >> +:Type: vm ioctl
> >> +:Parameters: struct kvm_arm_copy_mte_tags
> >> +:Returns: 0 on success, < 0 on error
> >> +
> >> +::
> >> +
> >> + struct kvm_arm_copy_mte_tags {
> >> + __u64 guest_ipa;
> >> + __u64 length;
> >> + union {
> >> + void __user *addr;
> >> + __u64 padding;
> >> + };
> >> + __u64 flags;
> >> + __u64 reserved[2];
> >> + };
> >
> > This doesn't exactly match the structure in the previous patch :-(.
>
> :( I knew there was a reason I didn't include it in the documentation
> for the first 9 versions... I'll fix this up, thanks for spotting it.
>
> >> +
> >> +Copies Memory Tagging Extension (MTE) tags to/from guest tag memory. The
> >> +``guest_ipa`` and ``length`` fields must be ``PAGE_SIZE`` aligned. The ``addr``
> >> +fieldmust point to a buffer which the tags will be copied to or from.
> >> +
> >> +``flags`` specifies the direction of copy, either ``KVM_ARM_TAGS_TO_GUEST`` or
> >> +``KVM_ARM_TAGS_FROM_GUEST``.
> >> +
> >> +The size of the buffer to store the tags is ``(length / MTE_GRANULE_SIZE)``
> >
> > Should we add a UAPI definition for MTE_GRANULE_SIZE?
>
> I wasn't sure whether to export this or not. The ioctl is based around
> the existing ptrace interface (PTRACE_{PEEK,POKE}MTETAGS) which doesn't
> expose a UAPI definition. Admittedly the documentation there also just
> says "16-byte granule" rather than MTE_GRANULE_SIZE.
>
> So I'll just remove the reference to MTE_GRANULE_SIZE in the
> documentation unless you feel that we should have a UAPI definition.
Dropping the mention of this symbol and replacing it by the value 16
matches the architecture and doesn't require any extra UAPI
definition, so let's just do that.
>
> >> +bytes (i.e. 1/16th of the corresponding size). Each byte contains a single tag
> >> +value. This matches the format of ``PTRACE_PEEKMTETAGS`` and
> >> +``PTRACE_POKEMTETAGS``.
> >> +
> >> 5. The kvm_run structure
> >> ========================
> >>
> >> @@ -6362,6 +6396,25 @@ default.
> >>
> >> See Documentation/x86/sgx/2.Kernel-internals.rst for more details.
> >>
> >> +7.26 KVM_CAP_ARM_MTE
> >> +--------------------
> >> +
> >> +:Architectures: arm64
> >> +:Parameters: none
> >> +
> >> +This capability indicates that KVM (and the hardware) supports exposing the
> >> +Memory Tagging Extensions (MTE) to the guest. It must also be enabled by the
> >> +VMM before the guest will be granted access.
> >> +
> >> +When enabled the guest is able to access tags associated with any memory given
> >> +to the guest. KVM will ensure that the pages are flagged ``PG_mte_tagged`` so
> >> +that the tags are maintained during swap or hibernation of the host; however
> >> +the VMM needs to manually save/restore the tags as appropriate if the VM is
> >> +migrated.
> >> +
> >> +When enabled the VMM may make use of the ``KVM_ARM_MTE_COPY_TAGS`` ioctl to
> >> +perform a bulk copy of tags to/from the guest.
> >> +
> >
> > Missing limitation to AArch64 guests.
>
> As mentioned previously it's not technically limited to AArch64, but
> I'll expand this to make it clear that MTE isn't usable from a AArch32 VCPU.
I believe the architecture is quite clear that it *is* limited to
AArch64. The clarification is welcome though.
M.
--
Without deviation from the norm, progress is not possible.
On 20/05/2021 11:24, Marc Zyngier wrote: > On Wed, 19 May 2021 15:09:23 +0100, > Steven Price <steven.price@arm.com> wrote: >> >> On 17/05/2021 19:09, Marc Zyngier wrote: >>> On Mon, 17 May 2021 13:32:39 +0100, >>> Steven Price <steven.price@arm.com> wrote: [...]>>>> +bytes (i.e. 1/16th of the corresponding size). Each byte contains a single tag >>>> +value. This matches the format of ``PTRACE_PEEKMTETAGS`` and >>>> +``PTRACE_POKEMTETAGS``. >>>> + >>>> 5. The kvm_run structure >>>> ======================== >>>> >>>> @@ -6362,6 +6396,25 @@ default. >>>> >>>> See Documentation/x86/sgx/2.Kernel-internals.rst for more details. >>>> >>>> +7.26 KVM_CAP_ARM_MTE >>>> +-------------------- >>>> + >>>> +:Architectures: arm64 >>>> +:Parameters: none >>>> + >>>> +This capability indicates that KVM (and the hardware) supports exposing the >>>> +Memory Tagging Extensions (MTE) to the guest. It must also be enabled by the >>>> +VMM before the guest will be granted access. >>>> + >>>> +When enabled the guest is able to access tags associated with any memory given >>>> +to the guest. KVM will ensure that the pages are flagged ``PG_mte_tagged`` so >>>> +that the tags are maintained during swap or hibernation of the host; however >>>> +the VMM needs to manually save/restore the tags as appropriate if the VM is >>>> +migrated. >>>> + >>>> +When enabled the VMM may make use of the ``KVM_ARM_MTE_COPY_TAGS`` ioctl to >>>> +perform a bulk copy of tags to/from the guest. >>>> + >>> >>> Missing limitation to AArch64 guests. >> >> As mentioned previously it's not technically limited to AArch64, but >> I'll expand this to make it clear that MTE isn't usable from a AArch32 VCPU. > > I believe the architecture is quite clear that it *is* limited to > AArch64. The clarification is welcome though. I explained that badly. A system supporting MTE doesn't have to have all CPUs running AArch64 - fairly obviously you can boot a 32 bit OS on a system supporting AArch64. Since the KVM capability is a VM capability it's not architecturally inconsistent to enable it even if all your CPUs are running AArch32 (at EL1 and lower) - just a bit pointless. However, given your comment that a mixture of AArch32/AArch64 VCPUs is a bug - we can fail creation of AArch32 VCPUs and I'll explicitly document this is a AArch64 only feature. Thanks, Steve
© 2016 - 2026 Red Hat, Inc.