|Subject:||Re: [Qemu-devel] [PATCH]ish NPTL support.|
|Date:||Wed, 13 Dec 2006 19:44:58 +0100|
|User-agent:||Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913|
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.
|[Prev in Thread]||Current Thread||[Next in Thread]|