> - 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 _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
