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