Re: [PATCH RFC 4/4] kvm: Implement atomic memory region resizes via region_resize()

[David Hildenbrand]

On 06.03.20 12:38, Paolo Bonzini wrote:
> On 06/03/20 11:20, David Hildenbrand wrote:
>> Yeah, rwlocks are not optimal and I am still looking for better
>> alternatives (suggestions welcome :) ). Using RCU might not work,
>> because the rcu_read region might be too big (esp. while in KVM_RUN).
>>
>> I had a prototype which used a bunch of atomics + qemu_cond_wait. But it
>> was quite elaborate and buggy.
>>
>> (I assume only going into KVM_RUN is really affected, and I do wonder if
>> it will be noticeable at all. Doing an ioctl is always already an
>> expensive operation.)
>>
>> I can look into per-cpu locks instead of the rwlock.
> 
> Assuming we're only talking about CPU ioctls (seems like a good
> approximation) maybe you could use start_exclusive/end_exclusive?  The
> current_cpu->in_exclusive_context assignments can be made conditional on
> "if (current_cpu)".
> 
> However that means you have to drop the BQL, see
> process_queued_cpu_work.  It may be a problem.
> 

Yeah, start_exclusive() is expected to be called without the BQL,
otherwise the other CPUs would not be able to make progress and can
eventually be "caught".

It's essentially the same reason why I can't use high-level
pause_all_vcpus()/resume_all_vcpus(). Will drop the BQL which is very
bad for resizing code.

-- 
Thanks,

David / dhildenb