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

[Sean Christopherson <seanjc@google.com>]

On Fri, Aug 07, 2026, Yosry Ahmed wrote:
> On Fri, Aug 7, 2026 at 7:26 AM Sean Christopherson <seanjc@google.com> wrote:
> > > AS_NO_DIRECT_MAP will surely make it a bigger problem, but not a new one :P
> >
> > Well, if it disallows GUP, that will be a new problem.
> 
> Yeah I think we should check here and allow GUP on unmapped pages
> (more below). One thing that confuses me is that the
> GUEST_MEMFD_FLAG_NO_DIRECT_MAP series [1] seems to also have this
> check that disallows GUP. So I am not sure if KVM needs GUP to work
> for guest_memfd now (then how does [1] work?) or it will need it to
> work in the future?

Well, there's a reason that series hasn't been merged. :-)

I didn't get far enough to start looking at the GUP stuff, so I genuinely don't
know if what it proposed is sane/correct.

> [1]https://lore.kernel.org/all/20260410151746.61150-7-kalyazin@amazon.com/
> 
> >
> > > > > > 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.
> >
> > Yes, though as I said early, it doesn't *have* to be exactly GUP, just something
> > GUP-like.  E.g. it could be a new API, if that's easier/cleaner.  What I don't
> > think is a good idea though is handling this entirely in KVM/guest_memfd.
> 
> Just to clarify, you mean that GUP (or GUP-like) should work in terms of
> pinning the page and handing KVM/guest_memfd the pfn/address, but not
> actually making the page accessible or establishing mappings, right?

No, I'm saying that whatever API the kernel provides needs to ensure there's a
valid kernel mapping (or provide one as a return value).  

> Looking at [2], seems like the consensus was that AS_NO_DIRECT_MAP
> means folios are not in the direct map, and callers are responsible
> for establishing the mappings (e.g. using the mermap).

I'm fine with that direction, but in that case GUP _does_ need to be disallowed.
I.e. _if_ we allow GUP, then GUP itself needs to somehow ensure the direct map
is populated.  If GUP is not allowed, then IMO the core kernel needs to provide
an API to get at "inaccessible" mappings.  Or I suppose GUP could take a flag
that says "I pinky-swear not to try and access the memory via the direct map".

> [2]https://lore.kernel.org/all/aeemS2wm38Cm4qAf@google.com/
> 
> >
> > > 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?
> >
> > And establish a (ephemeral?) kernel mapping, because general users of GUP will
> > expect that they can access the physical memory through the direct map.  That's
> > why I didn't want to handle any of this in KVM[*], the rules and handling need
> > to be kernel-wide.
> 
> See above, I am struggling to understand where you think establishing
> mappings should lie.  

Heh, I'm not surprised you're struggling, because I don't really have an opinion
on exactly who/what is responsible for establishing the mappings.  What I care
about at this point is not having guest_memfd itself provide a GUP-like API: that
needs to be a generic kernel API.

> The current approach is that AS_NO_DIRECT_MAP just means folios are not
> mapped, and users are responsible for establishing the mappings. I assume you
> agree with this (since you suggested this :P), but you don't want KVM to do
> this ad-hoc, but to have a library for it.
> 
> This library should be the mermap. I imagine (for e.g.) kvm_vcpu_map()
> using the mermap under the hood if it knows the mappings do not exist
> and using the mermap virtual address instead of the direct map
> address. This only works (with the current implementation) if we can
> disable migration (or even better, preemption) while a mapping is
> active, which I imagine would be tricky or just not possible.
> 
> The alternative could be destroying and recreating the mappings when
> the vCPU moves between CPUs, which is.. interesting :)
> 
> I imagine we don't have to sort all of this out now. For the purposes
> of AS_NO_DIRECT_MAP (and secretmem AFAICT), we just need to provide a
> facility to allocate unmapped pages. None of this is user-facing at
> this point.
> 
> >
> > [*] https://lore.kernel.org/all/aeemS2wm38Cm4qAf@google.com