[RFC PATCH 1/3] KVM: guest_memfd: Use memslot id to keep track of associated memslots

[David Hildenbrand]

On 7/6/26 23:43, Sean Christopherson wrote:
> On Thu, Jul 02, 2026, Alexandru Elisei wrote:
>> To enable memslot operations, KVM maintains two arrays of memslots, and an
>> RCU pointer to the active (in use) array. Changes are made first to the
>> inactive array, and the RCU pointer is updated to point to the inactive
>> array, which becomes active.
>>
>> The guest_memfd file maintains an xarray of pointers to memslots that use
>> it as the memory provider. After the RCU pointer to the active memslots is
>> updated and until SRCU is synchronized, readers can observe the old or the
>> new value for the active array, and therefore the old or the new pointer
>> for a given memslot.  For memslot creation or deletion that is not an issue
>> for guest_memfd, as readers will either read the same memslot pointer saved
>> by the guest_memfd file, or a non-existing memslot.
>>
>> But when changing the flags for a memslot, readers can read two different
>> and non-NULL memslot pointers. 
> 
> And?  Why does that matter?  KVM memslot updates aren't atomic.  Practically
> speaking, they _can't_ be made atomic.  Userspace is required to quiesce all
> activity that must not observe inconsistent state, i.e. userspace must pause
> (stop running) vCPUs when performing a memslot update.

I agree with that. It took us quite an effort to sort that out in QEMU.

I was especially when nasty when, some guest activity resulted in memslot splits
or merges, while some VCPUs were still active.

-- 
Cheers,

David