From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GuYFw-0000dH-T8 for qemu-devel@nongnu.org; Wed, 13 Dec 2006 12:51:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GuYFw-0000cr-5N for qemu-devel@nongnu.org; Wed, 13 Dec 2006 12:51:00 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GuYFv-0000ca-NF for qemu-devel@nongnu.org; Wed, 13 Dec 2006 12:50:59 -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 1GuYFv-0006rr-HY for qemu-devel@nongnu.org; Wed, 13 Dec 2006 12:50:59 -0500 Subject: Re: [Qemu-devel] [PATCH]ish NPTL support. From: David Woodhouse In-Reply-To: <200612131742.12393.paul@codesourcery.com> 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> Content-Type: text/plain Date: Wed, 13 Dec 2006 17:50:56 +0000 Message-Id: <1166032256.5253.766.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: Paul Brook Cc: qemu-devel@nongnu.org On Wed, 2006-12-13 at 17:42 +0000, Paul Brook wrote: > Qemu doesn't currently have any real thread support. It has a few hacks that > work for simple linuxthreads cases, but I doubt real multithreaded > applications will work. > > My point was that instead of blindly passing the threading syscalls through to > the host we should consider using the host libc/libpthread thread support. Well, let's break things down individually. - sys_set_thread_area(): - sys_get_thread_area(): - clone(CLONE_SETTLS) This _is_ handled in qemu, since it's just a case of loading new stuff into the emulated GDT. (Well, I didn't do get_thread_area but it's simple). - sys_futex(): We have to translate these into calls to the host's sys_futex() anyway. I need to go through the rest of the futex operations and see how many we can emulate cross-endian, and perhaps add some kernel support to make the answer "all of them". - 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. - clone(CLONE_PARENT_SETTID): - clone(CLONE_CHILD_SETTID): 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. -- dwmw2