From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GvZYV-000868-Ot for qemu-devel@nongnu.org; Sat, 16 Dec 2006 08:26:23 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GvZYU-00085h-3C for qemu-devel@nongnu.org; Sat, 16 Dec 2006 08:26:23 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GvZYT-00085c-TN for qemu-devel@nongnu.org; Sat, 16 Dec 2006 08:26:21 -0500 Received: from [213.146.154.40] (helo=pentafluge.infradead.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GvZYT-0000ZN-Lv for qemu-devel@nongnu.org; Sat, 16 Dec 2006 08:26:21 -0500 Subject: Re: [Qemu-devel] [PATCH]ish NPTL support. From: David Woodhouse In-Reply-To: <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> <20061214021623.GA3597@mail.shareable.org> Content-Type: text/plain Date: Sat, 16 Dec 2006 13:26:13 +0000 Message-Id: <1166275574.5253.1196.camel@pmac.infradead.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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 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