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

[Takahiro Itazuri <itazur@amazon.com>]

On Tue, 13 Oct 2026 08:36:54 -0700, Yosry Ahmed <yosry@kernel.org> wrote:
> > 3. ALLOC_UNMAPPED and the mermap
> >
> > AS_NO_DIRECT_MAP itself works without them, by zapping the direct map
> > of each folio. However, guest_memfd will eventually need a temporary
> > kernel mapping to populate guest memory via write() [2], because
> > folios are already unmapped once they are added to the page cache.
[...]
>
> FWIW, I think the mermap can still be used without ALLOC_UNMAPPED, and
> I did have a newer version of the x86 patches repurposing the LDT area
> for the mermap, and simplifying the mermap implementation a bit. I can
> share them privately if you want to take a look.

Yes please, that would be very helpful. Thanks!

Agreed that the mermap can be used without ALLOC_UNMAPPED. To give a
bit more context from the guest_memfd side: I can't say anything
definite until I've gone through the use cases, but as far as I can
see now, guest_memfd needs the mermap only for write() support.
write() is an optimization for populating guest memory (e.g. when
restoring a snapshot) and isn't functionally required, because
userspace can also populate guest memory through its own mapping of
guest_memfd. So I currently plan to keep write() support, and with it
the mermap, out of the guest_memfd direct map removal series itself.
Since ALLOC_UNMAPPED is the main user of the mermap, it may make more
sense for the two to land together later.

One thing I'd like to look into is arm64. Firecracker also runs on
arm64, so write() needs to work there too, but the mermap currently
relies on the x86 mm-local region, and it sounds like your newer
version relies on the LDT area. Kevin, do you happen to have any
ideas on how something similar could be done on arm64?

Thanks,
Takahiro