From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K1Kly-0007hI-0R for qemu-devel@nongnu.org; Wed, 28 May 2008 08:28:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K1Klw-0007gL-9E for qemu-devel@nongnu.org; Wed, 28 May 2008 08:28:53 -0400 Received: from [199.232.76.173] (port=34443 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1Klw-0007gG-5u for qemu-devel@nongnu.org; Wed, 28 May 2008 08:28:52 -0400 Received: from mail2.shareable.org ([80.68.89.115]:52680) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K1Klw-0005hG-1O for qemu-devel@nongnu.org; Wed, 28 May 2008 08:28:52 -0400 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1K1Klu-0005Lg-Jo for qemu-devel@nongnu.org; Wed, 28 May 2008 13:28:50 +0100 Date: Wed, 28 May 2008 13:28:50 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] Threading Qemu Message-ID: <20080528122850.GC19738@shareable.org> References: <20080527233155.d05f3f7a3b090fc6839dcb689abb911d.486e192adc.wbe@email.secureserver.net> <483D0C78.8020406@qumranet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <483D0C78.8020406@qumranet.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 Izik Eidus wrote: > it isn't about just give thread for each virtual CPU, > you will need to take care that atomic operations will translate > from one architecture to another architecture as atomic That's a bit work, but should be ok provided the host architecture has equivalent atomic ops, or equal-or-larger-width compare-and-swap instructions (from which you can make all atomic ops). Don't forget that simple write ops are atomic on most architectures. If you have to translate e.g. an 8-byte write to two 4-byte writes on a 32-bit host, that loses the atomic write property, which many programs depend on. > plus you will need to take care for memory barriers, and many more things > (it looks very complex) Don't forget _implied_ memory write barrier after every write op on x86 target. With x86 target on hosts where writes are not processor-ordered like x86, you need to put a write-write barrier after every write - except when you can prove it's not needed. But that's really hard. You can relax this, if you emulate particular x86 targets which have a "weak write mode". Some Linux guests, at least, will enable weak write mode on those - in that mode you can translate to faster code for the non-x86 host. Both atomiciy and ordering don't have to be solved if instead you use "software scheduled" threads on any architecture - e.g. see GNU Pth. Then you won't get real parallelism on a multiprocessor host, but you can simulate any multiprocessor target correctly. -- Jamie