| Message ID | 20210517123239.8025-9-steven.price@arm.com |
|---|---|
| State | New |
| Headers | show |
| Series | MTE support for KVM guest | expand |
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.
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.
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
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. ======================
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(+)