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

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

-- 
Cheers,

David