Takahiro Itazuri <[email protected]> writes:
>
> [...snip...]
>
Brought this topic up on the guest_memfd biweekly today!
>
> Agreed with both of you. I'll adopt the filemap-level approach:
>
> - Move the zap/restore hooks from guest_memfd into filemap_add_folio()
> / filemap_remove_folio().
> - Tighten AS_NO_DIRECT_MAP semantics so that, for folios in such a
> mapping, the direct map is invalid for the entire time the folio
> resides in the page cache.
> - Drop the per-folio KVM_GMEM_FOLIO_NO_DIRECT_MAP bookkeeping in
> folio->private, since the existence of the folio in the mapping is
> itself the state.
>
> On each guest memory population path,
>
> - memcpy-based population from userspace goes through the userspace
> mapping of guest_memfd, not through the kernel direct map, so the
> filemap-level invariant doesn't affect it. But this is slow, which
> is what motivated the write() syscall support.
>
> - write(): meant to speed up the userspace-memcpy case above by doing
> the copy in the kernel. I believe Brendan's __GFP_UNMAPPED/mermap
> work [1] would give us a low-overhead way to get temporary kernel
> access to an AS_NO_DIRECT_MAP. Landing mermap may take a while, but
> this series does not introduce the write() path, so mermap is not a
> blocker for now.
>
> - kvm_gmem_populate(): this is a TDX/SNP-only path, and NO_DIRECT_MAP
> is not available on those VM types —
> kvm_arch_gmem_supports_no_direct_map() returns false for
> KVM_X86_TDX_VM and KVM_X86_SNP_VM, which are its only callers
> today. So it doesn't interact with the filemap invariant IIUC.
>
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):
For non-in-place population where the source physical page is different
from the destination physical page,
+ TDX: the TDX module does the population and works with physical
addresses, so no issue with populate? Other parts of TDX may have
trouble though, but that can be handled later.
+ SNP: sev_gmem_post_populate() does a memcpy() after using
kmap_local_page()
Would mermap be a drop in replacement for kmap_local_page() here? Would
guest_memfd need to force a TLB flush after mermap+memcpy?
> So, unless I'm missing any path, adopting the filemap-level approach in
> this series should be fine.
>
>
> I'd like to consult with you folks on how to proceed in advance. In a
> separate reply on the cover letter thread [2], Lorenzo and Sean
> suggested that the mm pieces should go through the mm subsystem:
>
> On Tue, Apr 21, 2026 at 04:36:00PM +0000, Sean Christopherson wrote:
>> Yeah, when the time comes, the mm pieces definitely need to go through the mm
>> tree. Ideally, I think this would be merged in two separate parts, with all
>> mm
>> changes going through the mm tree, and then the KVM changes through the KVM
>> tree
>> using a stable topic branch/tag from Andrew.
>
> I see two reasonable paths to get there, and would appreciate your
> input on which you prefer:
>
> Path A — validate on KVM side first, then split:
> - Post v13 as a single series on the KVM list, gather feedback and
> make sure the design is acceptable to KVM reviewers.
> - Once v13 looks good ("the time comes"), do the MM/KVM split,
> rebase the MM part onto the appropriate MM branch, and post the
> MM part to linux-mm to build consensus with MM maintainers.
>
> Path B — split early and seek MM consensus in parallel:
> - With the filemap rework already in place, do the MM/KVM split
> now and post the MM part to linux-mm directly. The KVM part follows
> on top of a stable topic from MM.
>
> Which of the two would you rather see? Happy to go either way.
>
Vlastimil pointed out that there's a temporary limitation now that the
mm-tree cannot do stable branches shared between trees now.
I think it depends on how quickly you plan to refresh this series, but
Path A wouldn't be blocked by the temporary limitation.
My opinion would be to go ahead with a new revision (Path A) to fully
address comments before splitting the series. Any Reviewed-bys can be
carried over to the split series anyway :)
Alternatively you could wait till conversion lands :P Either one of us
will need to do more work for conversion wrt direct map removal.
>
> [1]
> https://lore.kernel.org/all/[email protected]/
> [2] https://lore.kernel.org/all/[email protected]/
>
> Takahiro
