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

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

Yup, I meant the latter.

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

This series is not adding the support in guest_memfd, just adding the
generic AS_NO_DIRECT_MAP and using it for secretmem. Followup work is
needed to plumb it for guest_memfd anyway, and I am proposing that we
also punt the GUP story to that (when we have an actual user).