| Message ID | 20210618132826.54670-8-steven.price@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | MTE support for KVM guest | expand |
On Fri, Jun 18, 2021 at 02:28:26PM +0100, Steven Price wrote: > +When this capability is enabled all memory in (non-device) memslots must not > +used VM_SHARED, attempts to create a memslot with a VM_SHARED mmap will result > +in an -EINVAL return. "must not used" doesn't sound right. Anyway, I'd remove VM_SHARED as that's a kernel internal and not something the VMM needs to be aware of. Just say something like "memslots must be mapped as shareable (MAP_SHARED)". Otherwise: Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
On 18/06/2021 15:52, Catalin Marinas wrote: > On Fri, Jun 18, 2021 at 02:28:26PM +0100, Steven Price wrote: >> +When this capability is enabled all memory in (non-device) memslots must not >> +used VM_SHARED, attempts to create a memslot with a VM_SHARED mmap will result >> +in an -EINVAL return. > > "must not used" doesn't sound right. Anyway, I'd remove VM_SHARED as > that's a kernel internal and not something the VMM needs to be aware of. > Just say something like "memslots must be mapped as shareable > (MAP_SHARED)". I think I meant "must not use" - and indeed memslots must *not* be mapped as shareable. I'll update to this wording: When this capability is enabled all memory in memslots must be mapped as not-shareable (no MAP_SHARED), attempts to create a memslot with MAP_SHARED will result in an -EINVAL return. > Otherwise: > > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> > Thanks, Steve
On Mon, Jun 21, 2021 at 09:18:31AM +0100, Steven Price wrote: > On 18/06/2021 15:52, Catalin Marinas wrote: > > On Fri, Jun 18, 2021 at 02:28:26PM +0100, Steven Price wrote: > >> +When this capability is enabled all memory in (non-device) memslots must not > >> +used VM_SHARED, attempts to create a memslot with a VM_SHARED mmap will result > >> +in an -EINVAL return. > > > > "must not used" doesn't sound right. Anyway, I'd remove VM_SHARED as > > that's a kernel internal and not something the VMM needs to be aware of. > > Just say something like "memslots must be mapped as shareable > > (MAP_SHARED)". > > I think I meant "must not use" - and indeed memslots must *not* be > mapped as shareable. I'll update to this wording: > > When this capability is enabled all memory in memslots must be mapped as > not-shareable (no MAP_SHARED), attempts to create a memslot with MAP_SHARED > will result in an -EINVAL return. It looks fine. Feel free to keep my reviewed-by.
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 22d077562149..3c27e712b1fb 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -5034,6 +5034,43 @@ 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: number of bytes copied, < 0 on error (-EINVAL for incorrect + arguments, -EFAULT if memory cannot be accessed). + +:: + + struct kvm_arm_copy_mte_tags { + __u64 guest_ipa; + __u64 length; + void __user *addr; + __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`` +field must 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 / 16)`` bytes +(granules in MTE are 16 bytes long). Each byte contains a single tag +value. This matches the format of ``PTRACE_PEEKMTETAGS`` and +``PTRACE_POKEMTETAGS``. + +If an error occurs before any data is copied then a negative error code is +returned. If some tags have been copied before an error occurs then the number +of bytes successfully copied is returned. If the call completes successfully +then ``length`` is returned. + 5. The kvm_run structure ======================== @@ -6362,6 +6399,30 @@ 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 creating any VCPUs to allow the guest access. Note that MTE is only +available to a guest running in AArch64 mode and enabling this capability will +cause attempts to create AArch32 VCPUs to fail. + +When enabled the guest is able to access tags associated with any memory given +to the guest. KVM will ensure 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 this capability is enabled all memory in (non-device) memslots must not +used VM_SHARED, attempts to create a memslot with a VM_SHARED mmap will result +in an -EINVAL return. + +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 | 61 ++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+)