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

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

Hi Sean,

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.

If guest_memfd picks up support for another feature that might lead to
memory being unmapped from stage 2 without userspace initiating it, would
you be ok with that feature being gated by another guest_memfd flag?

I get the feeling we're all on the same page, that guest_memfd will support
a mode where memory isn't unmapped from stage 2, and right now the
discussion is more about how that will be implemented.

Thanks,
Alex

> > 
> > 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.