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
