> If you're serious about multithreading TCG then I think the first > steps are: > * fix existing race conditions > * think very hard > * come up with an overall design for what you're proposing
As COREMU [1] point out, current QEMU atomic instruction emulation approach is problematic. For example, guest application might use x86 xchg instruction to implement spin lock/unlock (addr is a shared memory space). spin_unlock: spin_lock: try: r10 = 1; xchg addr, r10; if (r10 == 0) goto success; *addr = 0; fail: pause; if (*addr != 0) goto fail; goto try; success: After QEMU translation, guest xchg instruction becomes spin_unlock: spin_lock: helper_lock; *addr = 0; T0 = r10; T1 = *addr; *addr = T0; r10 = T1; helper_unlock; You can the see the atomicity on which spin lock/unlock rely is broken. "*addr = 0" can happened in the between of helper_lock/helper_unlock. COREMU solve this by using a lightway software transaction memory to emulate atomic instructions. I think this issue is quite important if we want to make TCG multithreaded, right? Is there a better way to solve this? Regards, chenwj [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.187.6011&rep=rep1&type=pdf -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj