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
