Re: [RFC PATCH 0/3] KVM: Dirty page logging for guest_memfd-only memslots

Hi Sean, David,

On Mon, Jul 13, 2026 at 04:11:57PM +0200, David Hildenbrand wrote:
> 
> >> That said, odds are good that we'll end up with per-gmem flags to communicate to
> >> guest_memfd whether or not the gmem instance supports page migration (x86's TDX
> >> and SNP in particular require extra consideration).  So if the anticipated use
> >> cases are fine with all-or-nothing "pinning", or with juggling guest_memfd files
> >> in userspace if a more dynamic setup is desired, then you should be ok?
> >>
> >> E.g. if the anticipated use cases are all slice-of-hardware style setups where
> >> the VM will be statically assigned a chunk of memory, then for the most part this
> >> will all Just Work.
> > 
> > Yeah. I agree (with the caveats you mention). Arm folk need to go figure
> > out if it's worthwhile to support with all those caveats.
> 
> Right, disabling migration (once gmem supports it) was also what I discussed
> with Alexandru when that topic comes up.
> 
> How to communicate to gmem that it wants these fixed mappings is a good question.

There's already a proposal for how to do this in the migratable guest_memfd
series [1] - it's a new guest_memfd creation flag that disables migration.

With Sean's comment that he expects swap/reclaim to be fully userspace
driven, I believe that would be enough to guarantee on the _kernel_ side
that SPE will work as intended for a guest.

I'm a slightly concerned though that all of this will work by chance, and
not by design, and in the future the behaviour might change to allow
guest_memfd memory to be unmapped from stage 2 without the VMM or KVM
explicitly allowing it or initiating it.

My understanding from the conversation so far is that the plan for the
future of guest_memfd is to support an option/mode where the memory is
effectively "pinned" at stage 2 (but which allows userspace to explicitly
free/unmap it, of course). Is that correct, or am I being overly optimistic
in my interpretation?

[1] https://lore.kernel.org/all/[email protected]/

Thanks,
Alex