From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GuaJ1-0002Rp-LV for qemu-devel@nongnu.org; Wed, 13 Dec 2006 15:02:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GuaIz-0002QI-VZ for qemu-devel@nongnu.org; Wed, 13 Dec 2006 15:02:18 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GuaIz-0002Q2-Ka for qemu-devel@nongnu.org; Wed, 13 Dec 2006 15:02:17 -0500 Received: from [84.96.92.56] (helo=smTp.neuf.fr) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GuaIz-0005wf-5D for qemu-devel@nongnu.org; Wed, 13 Dec 2006 15:02:17 -0500 Received: from [86.73.70.80] by sp604003mt.gpm.neuf.ld (Sun Java System Messaging Server 6.2-5.05 (built Feb 16 2006)) with ESMTP id <0JA800HZK6ODTF10@sp604003mt.gpm.neuf.ld> for qemu-devel@nongnu.org; Wed, 13 Dec 2006 19:43:26 +0100 (CET) Date: Wed, 13 Dec 2006 19:44:58 +0100 From: Fabrice Bellard Subject: Re: [Qemu-devel] [PATCH]ish NPTL support. In-reply-to: <200612131807.53555.paul@codesourcery.com> Message-id: <45804A2A.9090103@bellard.org> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <1165703896.5253.472.camel@pmac.infradead.org> <200612131742.12393.paul@codesourcery.com> <1166032256.5253.766.camel@pmac.infradead.org> <200612131807.53555.paul@codesourcery.com> 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 Paul Brook wrote: >>- 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. > > > The harm occurs if the host libc had per-thread state (eg. it has thread local > variables). If we bypass the host thread library then libc doesn't have > chance to initialize it's per-thread structures for that new thread, and bad > things are liable to happen then that thread uses libc functions. > > >>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. > > > Once you start proxying things to convert endianness I'd expect it to be > easier to just emulate everything. > > > Even when you implement all the syscalls qemu still won't work reliably. In > particular loads and stores will not be atomic. On real hardware a word > aligned load or store is guaranteed to complete atomically. qemu sometimes > splits these into multiple byte accesses, so the guest could see a partial > access. There are also memory ordering issues (x86 has comparatively strong > memory ordering guarantees, other hosts require a memory barrier to enforce > proper ordering). I've seen both these cause failures in in real > applications. > > Paul Another point is that the dynamic translator itself is not thread safe (I tried to implement thread safety a long time ago, but it is not finished). Using the pthreads may not be necessary provided we assume the host kernel supports NPTL. I don't think it is worth to spend time on the case where the host kernel does not support NPTL. Fabrice.