Re: [Qemu-devel] global_mutex and multithread.

[Mark Burton]

I think we call that flag “please dont reallocate this TB until at least after 
a CPU has exited and we do a global flush”… So if we sync and get all cpu’s to 
exit on a global flush, this flag is only there as a figment of our imagination…
e.g. we’re safe without it?

Wish I could say the same of global_mutex :-(


Cheers

Mark.

> On 15 Jan 2015, at 14:30, Frederic Konrad <address@hidden> wrote:
> 
> 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


         +44 (0)20 7100 3485 x 210
 +33 (0)5 33 52 01 77x 210

        +33 (0)603762104
        mark.burton