Re: [PATCH v3 03/26] mm: introduce AS_NO_DIRECT_MAP

[Sean Christopherson <seanjc@google.com>]

On Fri, Jul 31, 2026, Yosry Ahmed wrote:
> > > [..]
> > >> --- a/mm/gup.c
> > >> +++ b/mm/gup.c
> > >> @@ -11,7 +11,6 @@
> > >>  #include <linux/rmap.h>
> > >>  #include <linux/swap.h>
> > >>  #include <linux/swapops.h>
> > >> -#include <linux/secretmem.h>
> > >>  
> > >>  #include <linux/sched/signal.h>
> > >>  #include <linux/rwsem.h>
> > >> @@ -1216,7 +1215,7 @@ static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags)
> > >>  	if ((gup_flags & FOLL_SPLIT_PMD) && is_vm_hugetlb_page(vma))
> > >>  		return -EOPNOTSUPP;
> > >>  
> > >> -	if (vma_is_secretmem(vma))
> > >> +	if (vma_has_no_direct_map(vma))
> > >
> > > Same here, and for GUP in general. For example, KVM uses kvm_vcpu_map()
> > > to map guest memory and access it (e.g. when running nested
> > > virtualization), which uses GUP under the hood AFAICT. So KVM will want
> > > GUP to succeed, and probably create an ephemeral mapping as well.

This has actually been discussed quite heavily, on multiple occassions.  Once the
direct map is obliterated, there are basically two options:

 1. Establish ephemeral mappings (for a fairly loose definition of "ephemeral";
    some of the mappings would likely exist for the lifetime of the VM).

 2. Always access guest memory through userspace mappings, i.e. through uaccess.

#2 sounds nice, but the problem is that it effectively requires hand-coded assembly
sequences for anything more complex than basic load/store operations.  Which isn't
a complete non-starter, but it's a pretty big blocker.  E.g. see the mess that is
record_steal_time(), and then imagine trying to convert something like
nested_vmx_prepare_msr_bitmap() to use uaccess.

So, unless someone comes up with a clever idea, KVM will need something GUP-like.
Strictly speaking, it doesn't necessarily need to be exactly GUP, because KVM could
poke into guest_memfd directly; KVM would "just" need to manually track its own
mappings.  But on x86 at least, that's not really a viable option because it only
works for map-rarely, read/write-many use cases.  For one-off accesses, creating
and destroying (very) shortlived mappings would be too costly, and so we'd want
those to go through uaccess.  At that point, userspace is basically required to
maintain mappings for all host-accessible guest memory, and if there are userspace
mappings, then not using GUP doesn't make much sense.

Note, I called out x86 because x86 has the most extensive emulator and shadow
paging support, which is where the isolated, one-off accesses happen in spades.
Other architectures might be able to squeak by without userspace mappings, at
least for now.

So, in all likelihood, KVM will want GUP.

P.S. In theory, there are other options.  IIRC, arm64 hardware provides the ability
to access memory via stage-2 page tables, but I also recall it being broken and/or
having severe limitations.  Using that also seems like it would defeat the purpose
of nuking the direct map since the host would have a full view of guest memory, so
long as it had the right "key".

The other crazy hair super theoretical idea would be for KVM to hoist part of itself
into guest context, but that would be a hilariously costly version of uaccess, and
would never fly for CoCo VMs.