[Qemu-devel] qemu-i386 user mode on ARM

[Reuben K. Caron]

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