Re: [Qemu-devel] global_mutex and multithread.

[Frederic Konrad <fred.konrad@greensocs.com>]

On 15/01/2015 12:12, Paolo Bonzini wrote:
> [now with correct listserver address]
>
> On 15/01/2015 11:25, Frederic Konrad wrote:
>> Hi everybody,
>>
>> In case of multithread TCG what is the best way to handle
>> qemu_global_mutex?
>> We though to have one mutex per vcpu and then synchronize vcpu threads when
>> they exit (eg: in tcg_exec_all).
>>
>> Is that making sense?
> The basic ideas from Jan's patch in
> http://article.gmane.org/gmane.comp.emulators.qemu/118807 still apply.
>
> RAM block reordering doesn't exist anymore, having been replaced with
> mru_block.
>
> The patch reacquired the lock when entering MMIO or PIO emulation.
> That's enough while there is only one VCPU thread.
>
> Once you have >1 VCPU thread you'll need the RCU work that I am slowly
> polishing and sending out.  That's because one device can change the
> memory map, and that will cause a tlb_flush for all CPUs in tcg_commit,
> and that's not thread-safe.
>
> And later on, once devices start being converted to run outside the BQL,
> that can be changed to use new functions address_space_rw_unlocked /
> io_mem_read_unlocked / io_mem_write_unlocked.  Something like that is
> already visible at https://github.com/bonzini/qemu/commits/rcu (ignore
> patches after "kvm: Switch to unlocked MMIO").
>
> Paolo
>
>
>
Hi Paolo,

Thanks for the reply.

As I understand the idea of Jan is to unlock the global_mutex during tcg 
execution.
Is that right?
So that means it's currently not the case and we won't be able to run 
two TCG
threads at the same time?

About the RCU, is there a lot of device which change the memory map?

Thanks,
Fred