On Thu, 2006-12-14 at 02:16 +0000, Jamie Lokier wrote: > David Woodhouse wrote: > > - sys_futex(): > > > > We have to translate these into calls to the host's sys_futex() anyway. > > I don't think it's necessary to translate to the host's sys_futex(), > unless the guest will be doing futex operations on memory which the > host _also_ does futex operations on.
Yes, that observation makes sense. We just need proper locking against other qemu guest threads within the same process; nothing more. > CLONE_CHILD_CLEARTID is one of those, if it's simply relayed to the host. > So are locks in shared memory, if they are to work between host and > guest processes. But I guess they are not expected to work. Right. Those would be robust futexes -- and for the moment we can ignore them because we haven't implemented sys_set_robust_list() anyway. That would make life a whole lot more complicated, but I think we can do without it for now. > The atomicity, queueing etc. semantics, provided they are only among > threads of a single qemu process, can be guaranteed using normal > pthreads locking and atomic operations, analogous to the way the host > kernel maps futex calls to its own waitqueues, semaphores, and atomic > ops. Yes. We might also be able to cheat in a way inspired by the 'Big Kernel Lock' -- by pinning all threads to the same host CPU to help eliminate some of the locking issues. > However, it is probably easier to use the host's, than to write the > equivalent (basically duplicating the kernel's futex code in qemu, the > hashed locks and wait queues etc.). The kernel's implementation is a _whole_ lot more complicated than ours needs to be in qemu, because of the security implications of dealing with arbitrary pointers in userspace. I think it's reasonable enough for qemu to do its own. > On the other hand, using the host's makes it hard to run Linux guest > binaries on non-Linux hosts (those which don't have futex), or newer > Linux guest binaries on older Linux hosts which have fewer futex ops, > or none at all. I don't think we care. You can't run qemu-i386 on a non-Linux box _anyway_, can you? And having some syscalls return -ENOSYS if you run on a prehistoric kernel is perfectly normal. I did briefly think about implementing threading entirely within qemu _without_ using threads on the host -- having the qemu process itself schedule between the different CPU contexts. That would make the GDB stub a whole lot saner for debugging multi-threaded guest programs. But I don't think it's workable -- the whole point in NPTL was that you _can't_ emulate proper POSIX-compliant threading with hacks in userspace; especially the details of signal delivery. -- dwmw2 _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
