From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gug9K-0005U6-3r for qemu-devel@nongnu.org; Wed, 13 Dec 2006 21:16:42 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gug9G-0005Q5-9e for qemu-devel@nongnu.org; Wed, 13 Dec 2006 21:16:41 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gug9F-0005Pk-VS for qemu-devel@nongnu.org; Wed, 13 Dec 2006 21:16:38 -0500 Received: from [81.29.64.88] (helo=mail.shareable.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1Gug9F-0003vH-Oa for qemu-devel@nongnu.org; Wed, 13 Dec 2006 21:16:38 -0500 Date: Thu, 14 Dec 2006 02:16:23 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH]ish NPTL support. Message-ID: <20061214021623.GA3597@mail.shareable.org> References: <1165703896.5253.472.camel@pmac.infradead.org> <200612131722.17889.paul@codesourcery.com> <1166031123.5253.745.camel@pmac.infradead.org> <200612131742.12393.paul@codesourcery.com> <1166032256.5253.766.camel@pmac.infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1166032256.5253.766.camel@pmac.infradead.org> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Paul Brook 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