Re: [PATCH RFC] memory: pause all vCPUs for the duration of memory transactions

[Vitaly Kuznetsov <vkuznets@redhat.com>]

David Hildenbrand <david@redhat.com> writes:

> On 27.10.20 14:02, Vitaly Kuznetsov wrote:
>> 
>> Sorry for not being clear: your patch looks good to me, what I tried to
>> say is that with the current KVM API the only way to guarantee atomicity
>> of the update is to make vCPUs stop (one way or another), kicking them
>> out and preventing new IOCTLs from being dispatched is one way
>> (temporary pausing them inside KVM would be another, for example -- but
>> that would require *new* API supplying the whole transaction and not one
>> memslot update).
>
> Ah, got it.
>
> Yes - and I briefly looked into resizing slots inside KVM atomically and 
> it already turned out to be a major pain. All that metadata that's 
> allocated for a memory slot based on the size is problematic.
>

Yep, exactly and personally I'd rather refrain from doing more tricks
within KVM to keep the code simple. Generally, memslot updates should't
happen very often so pausing and resuming vCPUs should be acceptable
(that was one of the questions for this RFC).

Overall, I think we're in violent agreement here)

> Same applies to all other kinds of operations (splitting, punching out, 
> ...) as you also mentioned.

One question from a QEMU newbie though: why do you put
kvm_ioctl_inhibit_begin()/kvm_ioctl_inhibit_end() to kvm_region_resize()
only and not taking it all the way up to
memory_region_transaction_begin()/memory_region_transaction_end() to
support atomicity for all kinds of updates right away?

The second question is whether you plan to sumbit this any time soon)

Thanks!

-- 
Vitaly