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

[Sean Christopherson]

On Thu, Aug 06, 2026, Yosry Ahmed wrote:
> On Thu, Aug 6, 2026 at 5:02 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> >
> > On Fri, Jul 31, 2026, Yosry Ahmed wrote:
> 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.

They don't _need_ to be kept around that long, but I'm skeptical that on-demand
mapping will actually work for KVM's use cases.

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

I highly recommend testing shadow paging if you have aspirations of replacing
the get_user() in FNAME(walk_addr_generic) with an on-demand mapping.  I would
be (pleasantly) shocked if dynamic mappings can provide acceptable performance.

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

Doesn't what?  Have GUP?  KVM heavily uses GUP, including for guest_memfd that
can be mapped into userspace.