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

[Alexandru Elisei <alexandru.elisei@arm.com>]

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.

Thanks,
Alex