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

On Thu, Aug 6, 2026 at 5:02 PM Sean Christopherson <[email protected]> wrote:
>
> 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).

The mermap provides infrastructure to do this, but I think the
assumption is that mappings are short-lived. Keeping mappings for the
lifetime of the VM would probably need more thought. For example,
migration is disabled while a mapping is active (as mappings are
per-CPU), and I was even proposing disabling preemption (lol), so that
wouldn't work at all with mappings that are kept around for that long.
The address space is also currently limited to 2M per CPU per process,
which should be plenty but could also become a limitation.

>
>  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.

Ideally we can have shared infrastructure for this (i.e. the mermap).

> 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.

Not necessarily (I hope). I think the mermap pre-allocates page tables
(or some of them) and defers some TLB flushes, it's aimed at
short-lived mappings (e.g. for read() syscalls to map a file page,
copy to buffer, then unmap).

> 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.

Yeah I am thinking that the check here to disallow GUP completely for
unmapped pages is aggressive. Maybe it works for now if KVM does not
currently have any use cases for accessing guest_memfd memory. But if
it does (or will very soon), we need to think more about it, otherwise
AS_NO_DIRECT_MAP is not really usable for guest_memfd. Since you said
KVM "will want" GUP, I assume it currently doesn't?

>
> 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.