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

On Fri, Aug 14, 2026, Alexandru Elisei wrote:
> On Fri, Aug 14, 2026 at 06:03:54AM -0700, Sean Christopherson wrote:
> > 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.

Probably?  It's impossible to know what the exact flows will look like, but the
common theme for everything will be "don't break userspace".

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.