[RFC PATCH 2/3] KVM: Implement dirty page logging for guest_memfd-only memslots

[Kishen Maloor]

On 7/7/26 10:12 AM, Alexandru Elisei wrote:
> Hi Sean,
> 
> On Mon, Jul 06, 2026 at 06:29:11PM -0700, Sean Christopherson wrote:
>> On Thu, Jul 02, 2026, Alexandru Elisei wrote:
>>> The entire memory represented by guest_memfd-only memslot is shared and
>>> accessible by userspace.
>>
>> ...
>>
>>> +8.48 KVM_CAP_GUEST_MEMFD_MMAP_LOG_DIRTY_PAGES
>>> +---------------------------------------------
>>> +
>>> +:Architectures: all
>>> +
>>> +The presence of this capability indicates that memslots backed by a guest_memfd
>>> +file descriptor created with the GUEST_MEMFD_FLAG_MMAP flag can have dirty
>>> +page logging enabled.
>>
>> What does mmap() have to do with anything?  Supporting mmap() doesn't guarantee
>> the memory is shared, and I can't think of any dependency on memory actually
>> being mapped into userspace.
> 
> My bad, it should have been GUEST_MEMFD_FLAG_MMAP +
> GUEST_MEMFD_FLAG_INIT_SHARED. I'm not sure what you mean by "dependency on
> memory actually being mapped into userspace".
> 
>  From my point of view, it only makes sense to enable dirty page logging if
> the contents of the memory is accessible to userspace, hence I made dirty
> page logging depend on userspace having the option to access the memory.
> This can only happen if the guest_memfd file is mmap'able and accessible by
> userspace. But it doesn't force userspace to actually have the memory
> mapped to allow the log dirty pages flag to be set for a guest_memfd backed
> memslot. Hm.. now that I think about it, maybe I should have made depend on
> guest_memfd also having been created as shared? 


TDX live migration also needs to toggle KVM_MEM_LOG_DIRTY_PAGES on guest_memfd
memslots to use KVM's dirty logging infrastructure (the actual dirty
tracking for private pages is done out-of-band via SEAMCALLs). So this enabling
is needed, but it would be better to keep any logging eligibility decision in
an arch hook — e.g. gating on mmap/shared wouldn't work for TDX.


> Though I think that can be changed with KVM_SET_MEMORY_ATTRIBUTES on x86.
> 
> Does that answer your question?
> 
>> ...
>>> +			r = kvm_gmem_bind(kvm, new, mem->guest_memfd, mem->guest_memfd_offset);
>>> +		} else if (change == KVM_MR_FLAGS_ONLY) {
>>> +			r = kvm_gmem_change_flags(kvm, old, new, mem->guest_memfd,
>>> +						  mem->guest_memfd_offset);
>>> +		}
>>>   		if (r)
>>>   			goto out;
>>>   	}
>>> @@ -2117,7 +2117,7 @@ static int kvm_set_memory_region(struct kvm *kvm,
>>>   	return 0;
>>>   
>>>   out_unbind:
>>> -	if (mem->flags & KVM_MEM_GUEST_MEMFD)
>>> +	if ((mem->flags & KVM_MEM_GUEST_MEMFD) && change == KVM_MR_CREATE)
>>>   		kvm_gmem_unbind(new);
>>
>> This is wrong.  If kvm_set_memslot() failed, the old memslot needs to be bound
>> back to the guest_memfd instance.  Hmm, but KVM can't guarantee success.  So
> 
> The old memslot is still bound to guest_memfd in the sense that f->bindings
> still has the same memslot id+as_id assigned to the memslot's gpa range.


Whichever way it's handled, TDX will need this flags-only gmem update too.
A solution on the generic code path would be helpful.


> There's no rebinding happening when flags are changed because the memslot's
> id + as_id are not changed.