Re: [PATCH v2 5/7] KVM: arm64: MTE: Use stage-2 NoTagAccess memory attribute if supported

Catalin Marinas
2025-01-13T19:09:31Z

On Sat, Jan 11, 2025 at 06:49:55PM +0530, Aneesh Kumar K.V wrote:
> Catalin Marinas <catalin.marinas@arm.com> writes:
> > On Fri, Jan 10, 2025 at 04:30:21PM +0530, Aneesh Kumar K.V (Arm) wrote:
> >> Currently, the kernel won't start a guest if the MTE feature is enabled
>
> ...
>
> >> @@ -2152,7 +2162,8 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
> >> if (!vma)
> >> break;
> >>
> >> - if (kvm_has_mte(kvm) && !kvm_vma_mte_allowed(vma)) {
> >> + if (kvm_has_mte(kvm) &&
> >> + !kvm_has_mte_perm(kvm) && !kvm_vma_mte_allowed(vma)) {
> >> ret = -EINVAL;
> >> break;
> >> }
> >
> > I don't think we should change this, or at least not how it's done above
> > (Suzuki raised a related issue internally relaxing this for VM_PFNMAP).
> >
> > For standard memory slots, we want to reject them upfront rather than
> > deferring to the fault handler. An example here is file mmap() passed as
> > standard RAM to the VM. It's an unnecessary change in behaviour IMHO.
> > I'd only relax this for VM_PFNMAP mappings further down in this
> > function (and move the VM_PFNMAP check above; see Suzuki's internal
> > patch, unless he posted it publicly already).
>
> But we want to handle memslots backed by pagecache pages for virtio-shm
> here (virtiofs dax use case).

Ah, I forgot about this use case. So with virtiofs DAX, does a host page
cache page (host VMM mmap()) get mapped directly into the guest as a
separate memory slot? In this case, the host vma would not have
VM_MTE_ALLOWED set.

> With MTE_PERM, we can essentially skip the
> kvm_vma_mte_allowed(vma) check because we handle all types in the fault
> handler.

This was pretty much the early behaviour when we added KVM support for
MTE, allow !VM_MTE_ALLOWED and trap them later. However, we disallowed
VM_SHARED because of some non-trivial race. Commit d89585fbb308 ("KVM:
arm64: unify the tests for VMAs in memslots when MTE is enabled")
changed this behaviour and the VM_MTE_ALLOWED check happens upfront. A
subsequent commit removed the VM_SHARED check.

It's a minor ABI change but I'm trying to figure out why we needed this
upfront check rather than simply dropping the VM_SHARED check. Adding
Peter in case he remembers. I can't see any race if we simply skipped
this check altogether, irrespective of FEAT_MTE_PERM.

--
Catalin