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