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

On Wed, Aug 19, 2026, David Hildenbrand wrote:
> On 8/14/26 18:58, Alexandru Elisei wrote:
> > Hi,
> > 
> > On Fri, Aug 14, 2026 at 06:03:54AM -0700, Sean Christopherson wrote:
> >> 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.
> > 
> > My naive contribution is this idea I had:
> > 
> > 1. Userspace queries support in KVM for feature xyz by checking the
> > capability KVM_CAP_xyz.
> > 
> > 2. Userspace knows that for feature xyz to work correctly, it is required
> > that memory remains mapped at stage 2.
> > 
> > 3. Userspace creates a guest_memfd instance with the right combination of
> > flags set and _unset_ for feature xyz to work correctly - i.e, to keep
> > memory mapped at stage 2.
> > 
> > For this to work, new guest_memfd features that might lead to memory being
> > unmapped are enabled via a flag, and KVM keeps memory mapped at stage 2 by
> > default, to maintain compatibility with an userspace not updated for the
> > new features/flags.
> 
> I was wondering whether KVM could be driving that setting in guest_memfd, with
> less userspace intervention.
> 
> 1. Userspace enables support in KVM for feature xyz through
> capability KVM_CAP_xyz.
> 
> 2. KVM knows that the feature, on the current hardware requires permanent S2
> mapping, so it instructs guest_memfd to disable any features that could lead to
> a temporary unmapping (e.g.,migration support).

Yes, that's what I would like to aim for as well[*], with the understanding that
things may not play out exactly as we want if/when we actually implement all of
this.

 : We might make guest_memfd page migration opt-in, but if all of the incompatible
 : setups can enumerate their existence prior to creating guest_memfd files, we may
 : handle it all automatically, e.g. enable page migration by default, but disable
 : it if a TDX, SNP, pKVM, or SPE-capable VM is detected.

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