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 <fred.kon...@greensocs.com> 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
