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

[Sean Christopherson <seanjc@google.com>]

On Fri, Aug 14, 2026, David Hildenbrand wrote:
> We have a hardware feature that requires pages to always be mapped into S2. Some
> things I had in mind:
> 
> 1) Page migration would not be a problem as long as hardware could be paused
>    while migrating (e.g., kick all vCPUs). I doubt someone would implement that
>    right now,  but you could consider it an implementation detail that page
>    migration cannot be supported right now.
> 
> 2) Newer hardware could mitigate this problem, allowing the feature to support
>    pages temporarily being unmapped from S2.
> 
> 3) Disallowing page migration is really just one implication of "pages must
>    always be mapped into S2".
> 
> So what we really want is "if feature X is enabled and hardware requires it,
> always keep pages mapped into S2, which currently implies that page migration
> cannot be supported."
> 
> Which isn't all that different to "if a confidential VM is run on current TDX
> hardware, always keep pages mapped into S2, which currently implies that page
> migration cannot be supported."
> 
> So I was wondering whether the flow could be:
> 
> User space enabled CPU feature for VM -> KVM knows that current hardware
> requires for that CPU feature to have S2 always mapped -> KVM tells guest_memfd
> that S2 must be always mapped / disables page migration.

I'm a-ok with adding a flag to guest_memfd to communicate whether or not page
migration is allowed, because guest_memfd needs to actively support page migration.

I'm not ok adding a flag telling guest_memfd that memory must always be mapped
in S2, because guest_memfd doesn't care.  E.g. KVM doesn't yet support page
migration for SNP, but SNP tracks page ownership in an out-of-band table and so
KVM can map/unmap all guest memory from S2 at will.

> That would be in contrast to user space having to guess that page migration on
> the current hardware with the current guest_memfd implementation does not
> support page migration, to then disable exactly that.
> 
> Does that explanation makes sense? I don't know the exact mechanism to do that,
> but that's just my high-level thinking.

Yes, I'm supportive of KVM expressing to guest_memfd that page migration isn't
supported by the VM.  I'm only objecting to expressing that memory must stay
mapped in S2, because guest_memfd doesn't care *why* page migration is or isn't
supported/allowed by a particular VM.