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

[Sean Christopherson <seanjc@google.com>]

On Fri, Aug 07, 2026, Yosry Ahmed wrote:
> > > > > > > > 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".
> 
> Okay in this case I think the simplest thing to do here is to disallow GUP
> for unmapped pages like this patch does. Once we have a use case (e.g.
> guest_memfd with unmapped memory using GUP), we can figure out if we want a
> separate API or a GUP flag. I assume the GUP flag could either be: "I know
> the page is unmapped, I will map it" or "create an ephemeral mapping for the
> page".

I'm not ok punting on that, i.e. whatever we come up with needs to land alongside
AS_NO_DIRECT_MAP, or at least before guest_memfd tries to use AS_NO_DIRECT_MAP.
The only way KVM can use AS_NO_DIRECT_MAP without GUP is with a massive list of
caveats and addendums on things the VMM and guest can't do.  I'm not ok merging
guest_memfd support for AS_NO_DIRECT_MAP with such a list.