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
