On 17.12.14 11:27, Frederic Konrad wrote: > On 16/12/2014 17:37, Peter Maydell wrote: >> On 16 December 2014 at 09:13, <fred.kon...@greensocs.com> wrote: >>> From: KONRAD Frederic <fred.kon...@greensocs.com> >>> >>> This adds a lock to avoid multiple exclusive access at the same time >>> in case of >>> TCG multithread. > Hi Peter, > >> This feels to me like it's not really possible to review on >> its own, since you can't see how it fits into the design of >> the rest of the multithreading support. > true the only thing we observe is that it didn't change anything right now. > >> The other approach here rather than having a pile of mutexes >> in the target-* code would be to have TCG IR support for >> "begin critical section"/"end critical section". Then you >> could have the main loop ensure that no other CPU is running >> at the same time as the critical-section code. (linux-user >> already has an ad-hoc implementation of this for the >> exclusives.) >> >> -- PMM >> > What do you mean by TCG IR?
TCP ops. The nice thing is that TCG could translate those into transactions if the host supports them as well. Alex
