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

[Fabrice Bellard <fabrice@bellard.org>]

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.