Paul Brook wrote:
- sys_set_tid_address():
- clone(CLONE_CHILD_CLEARTID):
We _could_ manage to do this in qemu for controlled thread exit -- it
would be hard for uncontrolled exit though. But I don't see any harm in
just letting the kernel do it either. I don't mind too much, but if we
can let the kernel do it I'm happier that way.
The harm occurs if the host libc had per-thread state (eg. it has thread local
variables). If we bypass the host thread library then libc doesn't have
chance to initialize it's per-thread structures for that new thread, and bad
things are liable to happen then that thread uses libc functions.
We need endianness-mangling on these so we have to get involved somehow.
But I think we do need to use the kernel's support and then marshal the
result back to the guest's memory.
Once you start proxying things to convert endianness I'd expect it to be
easier to just emulate everything.
Even when you implement all the syscalls qemu still won't work reliably. In
particular loads and stores will not be atomic. On real hardware a word
aligned load or store is guaranteed to complete atomically. qemu sometimes
splits these into multiple byte accesses, so the guest could see a partial
access. There are also memory ordering issues (x86 has comparatively strong
memory ordering guarantees, other hosts require a memory barrier to enforce
proper ordering). I've seen both these cause failures in in real
applications.
Paul
Another point is that the dynamic translator itself is not thread safe
(I tried to implement thread safety a long time ago, but it is not
finished).
Using the pthreads may not be necessary provided we assume the host
kernel supports NPTL. I don't think it is worth to spend time on the
case where the host kernel does not support NPTL.
Fabrice.
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
