Re: [Qemu-devel] [PATCH]ish NPTL support.

[Paul Brook <paul@codesourcery.com>]

> - 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