From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MsNfJ-00022H-HF
	for qemu-devel@nongnu.org; Mon, 28 Sep 2009 17:21:49 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MsNfE-00021R-Jq
	for qemu-devel@nongnu.org; Mon, 28 Sep 2009 17:21:48 -0400
Received: from [199.232.76.173] (port=34902 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MsNfE-00021O-9h
	for qemu-devel@nongnu.org; Mon, 28 Sep 2009 17:21:44 -0400
Received: from mx1.redhat.com ([209.132.183.28]:51033)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <glommer@redhat.com>) id 1MsNfC-0002ri-JU
	for qemu-devel@nongnu.org; Mon, 28 Sep 2009 17:21:43 -0400
Date: Mon, 28 Sep 2009 18:21:24 -0300
From: Glauber Costa <glommer@redhat.com>
Subject: Re: [Qemu-devel] Main loop
Message-ID: <20090928212124.GP29735@mothafucka.localdomain>
References: <Pine.LNX.4.64.0909270343220.4611@linmac.oyster.ru>
	<4ABEB6B3.4010102@codemonkey.ws>
	<Pine.LNX.4.64.0909271448440.3924@linmac.oyster.ru>
	<4ABF7137.1040502@codemonkey.ws>
	<Pine.LNX.4.64.0909271835500.2147@linmac.oyster.ru>
	<20090928135723.GK29735@mothafucka.localdomain>
	<Pine.LNX.4.64.0909282246530.2983@linmac.oyster.ru>
	<4AC10FFC.9070509@codemonkey.ws>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4AC10FFC.9070509@codemonkey.ws>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org

On Mon, Sep 28, 2009 at 02:35:24PM -0500, Anthony Liguori wrote:
> malc wrote:
>> Now that we have talked i see the problem and it basically boils down
>> to this: kvm can(and does) run multiple vcpus in multiple threads,
>> qemu always uses one, on top of this you are mainly interested in KVM
>> and i'm _only_ interested in TCG.
>
> The multiple vcpus in multiple threads model is the right one for TCG  
> too.  Both Paul and Fabrice have expressed interest in this in the past.  
> For certain architecture combinations, it may not be that bad to  
> implement either.
>
>>  The way i see it the best approach
>> would be to factor out main loop into separate file and let QEMU and
>> KVM go their own separate ways w.r.t. this new entity.
>>   
> OTOH, if most of the heavy lifting (like IO dispatch) can be refactored  
> to shared functions, two main loops may not be so bad.
I am not opposed to it either.