Re: [Qemu-devel] global_mutex and multithread.

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

On 15/01/2015 12:14, Alexander Graf wrote:
>
> On 15.01.15 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.
> You'll have a similar problem for tb_flush() if you use a single tb
> cache. Just introduce a big hammer function for now that IPIs all the
> other threads, waits until they halted, do the atomic instruction (like
> change the memory map or flush the tb cache), then let them continue.
>
> We can later one-by-one get rid of all callers of this.
>
>
> Alex
Maybe we can put a flag in the tb to say it's being executed so tb_alloc 
won't try to
realloc it?

Maybe it's a bad idea and will be actually slower than exiting and 
waiting all the other
cpu.

Fred