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

[Yosry Ahmed]

On Thu, Aug 6, 2026 at 5:19 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> 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.

Fair.

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

Oh I was thinking of existing cases where KVM uses kernel mappings
(e.g. kvm_vcpu_map()), as these are the ones where KVM uses GUP now,
and need to work for AS_NO_DIRECT_MAP to be usable. I assume the
get_user() calls are already a problem for guest_memfd.
AS_NO_DIRECT_MAP will surely make it a bigger problem, but not a new
one :P

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

Your wording made me think that KVM doesn't currently use GUP for
guest_memfd, but I was obviously wrong. So IIUC GUP needs to succeed
for guest_memfd pages with AS_NO_DIRECT_MAP. To actually access the
memory, I assume the guest_memfd side will need to handle this by
either using ephemeral mappings (e.g. mermap), restoring and zapping
direct mappings, or using a userspace mapping. I suppose for the
purposes of AS_NO_DIRECT_MAP core support we just need GUP to succeed?