From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LpLNc-0006ye-NW for qemu-devel@nongnu.org; Thu, 02 Apr 2009 07:46:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LpLNX-0006yQ-Ln for qemu-devel@nongnu.org; Thu, 02 Apr 2009 07:46:43 -0400 Received: from [199.232.76.173] (port=42390 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LpLNX-0006yN-Iu for qemu-devel@nongnu.org; Thu, 02 Apr 2009 07:46:39 -0400 Received: from mx20.gnu.org ([199.232.41.8]:17739) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LpLNX-0002va-8R for qemu-devel@nongnu.org; Thu, 02 Apr 2009 07:46:39 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LpLNU-0006mg-DY for qemu-devel@nongnu.org; Thu, 02 Apr 2009 07:46:37 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Qemu threading support? Date: Thu, 2 Apr 2009 11:46:31 +0000 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904021246.32389.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 Cc: doremi On Thursday 02 April 2009, doremi wrote: > Hello, > > These days I have to add multi-threading support for Qemu (Performace > is not important for me). If performance is not important then why are you trying to do this? There's a good chance that the synchronisation overhead will be greater than the benefit of using multiple CPU cores. i.e. a multithreaded qemu will run slower than the current single threaded code. > But it's very complicated, could anybody do me a favor? Thanks As you say, it's a hard problem. Try searching the mailing lists, this has been discussed a several times before. Most of qemu is not threadsafe, so needs to be locked appropriately. Chances are the only thing you're realistically going to be able to run in parallel is the actual translated code. Even then it's not straightforward because you have to ensure MMIO callbacks get proper locking. You also have to make sure that all atomicity, ordering and coherency guarantees provided by the guest ISA are honored. Chances are that guest atomic operations will not be atomic after translation, and the host does not provide the memory ordering and coherency guarantees that the guest required. These problems can occur even for the x86 on x86 because the guest may require strongly ordered regions via PAT bits or MTRRs. Paul