Re: [PATCH v12 10/16] KVM: guest_memfd: Add flag to remove from direct map

[Lorenzo Stoakes <ljs@kernel.org>]

On Fri, Jul 10, 2026 at 08:50:25AM +0000, Brendan Jackman wrote:
> On Mon Jul 6, 2026 at 11:09 PM UTC, Sean Christopherson wrote:
> > On Fri, Jul 03, 2026, Brendan Jackman wrote:
> >> There are also the fault paths though; if the pages are nonpresent in
> >> the direct map for the duration of their life in the page cache (and I
> >> think they should be) then by the time we get to
> >> kvm_mmu_faultin_pfn_gmem() or kvm_gmem_fault_user_mapping() we lost the
> >> ability to zero them.
> >>
> >> My original answer for this was "that's fine, we'll use __GFP_ZERO
> >> (which will probably use the mermap under the hood)", but now I've
> >> realised there's a good reason we don't set __GFP_ZERO at the moment,
> >> namely that it's wasted if we end up doing kvm_gmem_populate()
> >
> > Eh, don't worry about the wasted cycles for populate().  The overhead of zeroing
> > a page is dwarfed by the overhead of adding (and in most cases, measuring) the
> > page.
> >
> > We (KVM folks) discussed this in the context of in-place conversions, and long
> > story short, the consensus is that shaving cycles by eliding the zeroing in the
> > host isn't worth the complexity.
>
> OK thanks, this is useful. Nonetheless because it leads to a less
> confusing dishgn, I think it still makes sense to just disallow
> __GFP_ZERO for the unmapped pages.
>
> (At least, at the page allocator level. We might want to allow it in
> address_space.gfp_mask or something and have filemap.c deal with it.
> But, overloading a GFP flag like this is yucky, if we need a flag for
> that I think it's likely neater to make it an AS_ flag or something).
>
> >> (Continued below...)
> >>
> >> > I'm a little bit uncomfortable this statement since it seems to say TDX
> >> > and SNP aren't taken care of. Would just like to discuss (for
> >> > a line of sight to SNP and TDX support):
> >>
> >> Are you saying we need NO_DIRECT_MAP support for TDX/SNP? I think that
> >> would be doable but what's the value?
> >
> > Hardening against consumption of shared memory?  Yes, the guest has explicitly
> > shared the memory so there are (very) reduced expectations around confidentiality
> > and integrity, but defense in depth and all that.
>
> Ah yeah, it did not occur to me that there was memory being set up via
> CoCo paths that is not encrypted. So yeah that makes perfect sense.
> Eventually we'll want to be able to lean on this to protect that shared
> memory against attacks by other VMs etc.
>
> > For me, the main thing is that I don't want to completely punt on the interaction
> > of the two things, and end up with an unworkable mess if there's ever a strong
> > reason for CoCo VMs to support NO_DIRECT_MAP.
>
> Yeah that makes sense.
>
> >> So that we can get a #PF instead of #MCE if we screw up?
> >
> > Note, SNP gets a #PF either way.
> >
> >> NOW, the thing I'm stuck on (again lol) is the patchset-fu. Here's all
> >> the parts we need, with dependencies indented:
> >>
> >> 0. efficient GUEST_MEMFD_FLAG_NO_DIRECT_MAP
> >>   1. AS_NO_DIRECT_MAP
> >>     2. ALLOC_UNMAPPED (formerly known as __GFP_UNMAPPED)
> >>       3. alloc_flags arg to the page allocator (I'm sneakily introducing this
> >>          in [1])
> >>       4. freetype_t
> >>   5. The mermap
> >>     6. The mm-local region
> >>
> >> I originally posted all of those in [0], except part 3. Doing all of
> >> that together in one series would be a bit too much though. Approaches I
> >> can see to avoid that:
> >>
> >> Approach X:
> >> - Do parts 1, 2 and 4 as a standalone series. The only beneficiary of
> >>   AS_NO_DIRECT_MAP would be secretmem.
> >> - Then another series that fills in 0, 5 and 6.
> >>
> >> Approach Y:
> >> - One series that does parts 0, 1, 5, and 6. AS_NO_DIRECT_MAP is
> >>   implemented by having filemap.c itself call folio_zap_direct_map(),
> >>   then guest_memfd.c zeroes it via the mermap. It works but it's really
> >>   slow.
> >> - Then another series that fills in parts 2 and 4, switches filemap.c
> >>   over from manual folio_zap_direct_map() to ALLOC_UNMAPPED, making
> >>   things fast.
> >>
> >> Approach X seems natural from a code progression perspective but leaves
> >> us with an interim phase where we have a bunch of complexity just to
> >> "optimise secretmem" which nobody cares about.
> >>
> >> Approach Y seems natural from a feature progression perspective but
> >> leaves us with an interim phase where we expensively zap a page, only to
> >> then immediately do this complex mermap dance to access it right
> >> afterwards.
> >>
> >> Any thoughts / other ideas? Personally I think I prefer X.
> >
> > I don't have preference between those options, mostly because I don't appreciate
> > the difference.  My overarching preference is to separate the mm/ work from the
> > guest_memfd as much as possible.  Beyond that, I probably don't care all that much?
>
> Cool thanks, shrugs are fine here.
>
> Main thing I'm trying to do here is generate some awareness that the
> decision is being made, so that I don't forge ahead with X and then have
> people going "ugh, why haven't you considered Y?" If nobody cares either
> way then nothing to worry about.

X seems fine to me and that seems to be the consensus here. And it seems moot if
Y relies upon mm stable branches which are not here yet :)

Cheers, Lorenzo