From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K1Kl4-0007Ld-Qb for qemu-devel@nongnu.org; Wed, 28 May 2008 08:27:59 -0400 Received: from [199.232.76.173] (port=34416 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1Kl4-0007LQ-DN for qemu-devel@nongnu.org; Wed, 28 May 2008 08:27:58 -0400 Received: from mx1.polytechnique.org ([129.104.30.34]:38208) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K1Kl4-0005U9-Dj for qemu-devel@nongnu.org; Wed, 28 May 2008 08:27:58 -0400 Received: from fbe1.dev.netgem.com (gw.netgem.com [195.68.2.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTP id D948333173 for ; Wed, 28 May 2008 14:27:54 +0200 (CEST) Message-ID: <483D4FC8.5080708@bellard.org> Date: Wed, 28 May 2008 14:27:52 +0200 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] Threading Qemu References: <20080527233155.d05f3f7a3b090fc6839dcb689abb911d.486e192adc.wbe@email.secureserver.net> <483D0C78.8020406@qumranet.com> In-Reply-To: <483D0C78.8020406@qumranet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 Izik Eidus wrote: > mixado@mod-x.com wrote: >> Hi, >> >> To make use of all the host CPU cores I'm thinking of adding thread >> support to Qemu. >> The idea so far is to create one thread for each virtual CPU, and then >> run a modified main_loop in each of these threads. >> The first step would be to rewrite all the global variables like >> first_cpu etc to make it more thread friendly, and make that run in the >> current non-threaded version. >> >> Any hints or tips that I should keep in mind when attempting this? Has >> thread support been worked on before but not completed? >> > 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 > plus you will need to take care for memory barriers, and many more things > (it looks very complex) I confirm, the general case is quite complicated. It is simpler to begin with an implementation where the host and guest CPUs have the same memory ordering constraints (e.g. x86 on x86 case). Fabrice.