Qemu Dev's, I have been reading through many mail archives about the issues with threading in qemu-i386 user mode.
I am writing now because here at One Laptop per Child we have a deployment looking to run simple Windows x86 executables using WINE on our new ARM platform. We are interested to know if there is an opportunity to fund a solution to this issue and if so, what kind of timeline could we expect for such a solution. If you are interested in working on such a project please feel free to get in touch with me off-list. I recently had an email exchange with Peter Maydell, where he kindly illustrated what he considered the major issues: "You can probably divide the work into three parts: (1) bringing target-i386 up to par with other targets for multithreaded user programs (ie "works, but prone to random crashes if using threads extensively"). This mostly amounts to enabling the NPTL config setting, making sure we're handling TLS correctly and fixing the issues with cross-thread exclusive accesses (x86 LOCK prefix). (2) fixing qemu user-mode's general multithreading crashiness (ie finding and fixing race conditions in core code). I actually have a patch lurking somewhere which deals with the worst one of these. (3) fixing any qemu user-mode emulation issues exposed by the particular binaries you want to run. This is the "how long is a piece of string" part, since you just have to keep fixing bugs until the program runs. Simple programs don't generally have issues here, but something complicated like Wine (I assume you're going to be using Wine to run these Windows binaries) probably does a few odd things that might give QEMU trouble. Most of these fixes will be easy, but you might be unlucky. (For instance there's a known issue trying to run programs which use the Boehm garbage collector, whose fix is basically "restructure the whole of linux-user mode so we can deal with signals arriving in the middle of emulating system calls".) (4) the nasty issue referred to above. This is specific to running a strong-memory-model target like x86 on a weak memory model host like ARM. QEMU just translates loads and stores to loads and stores, so multithreaded programs that rely on guarantees of the memory model about what order other threads see memory accesses in might behave oddly, because QEMU won't provide those guarantees. I have no idea whether this would be an issue for real world code; issues 1 to 3 are effectively hiding it. If it does turn out to be a real problem, though, there's not much we can do about it (short of emitting a memory barrier for every load/store op, which would probably do bad things for performance)." Regards, Reuben
