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

[Yosry Ahmed]

On Thu, Sep 3, 2026 at 12:27 AM Takahiro Itazuri <itazur@xxxxxxxxxx> wrote:
>
> Some of you on the KVM side already know this, but for those on the MM
> side who may not, I am taking over the guest_memfd direct-map removal
> series.  I have finally caught up with this thread, and I sincerely
> apologize for joining so late; other commitments kept me from catching
> up sooner.

Hi Takahiro!

>
> On Fri, 7 Aug 2026 15:48:24 -0700, Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
> > > 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).
>
> My reading of the discussion is that the generic AS_NO_DIRECT_MAP support
> can land with GUP rejecting such mappings, provided that a generic GUP-like
> access mechanism is in place before guest_memfd starts using
> AS_NO_DIRECT_MAP.

That's my understanding as well.

> As far as I know, Brendan is no longer at Google.  I do not know whether
> he plans to continue the ALLOC_UNMAPPED / mermap work, or whether someone
> else at Google has taken it over.

I am currently working on a new version of the ALLOC_UNMAPPED series,
I am hoping to send something out soon.

> If that work is not already underway,
> I would like to respin the AS_NO_DIRECT_MAP introduction and secretmem
> adoption as a standalone MM series, separate from ALLOC_UNMAPPED and
> mermap.  The AS_NO_DIRECT_MAP changes originated in the guest_memfd
> direct-map removal series, and splitting the MM and KVM parts was already
> requested during review.
>
> The proposed MM series would include:
>
>   - the folio direct-map helpers;
>   - the AS_NO_DIRECT_MAP flag and filemap lifecycle;
>   - the current GUP and build-ID rejections, while keeping the mlock
>     check specific to secretmem; and
>   - the secretmem conversion.
>
> I would leave ALLOC_UNMAPPED, freetypes, mermap, the allocator fast path,
> and the KVM / guest_memfd integration out of that series.  This would not
> change the requirement discussed by Sean and Yosry above: the GUP-like
> access problem would still need to be resolved before enabling
> AS_NO_DIRECT_MAP for guest_memfd.
>
> Please let me know if this work is already being continued; if not, does
> the standalone MM series described above sound reasonable?

Perhaps wait until I send the new version, then we can discuss if we
want to split it based on how the feedback looks like. Does this work
for you?