From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LHf3q-0004BE-1n for qemu-devel@nongnu.org; Tue, 30 Dec 2008 08:55:06 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LHf3k-00048m-JN for qemu-devel@nongnu.org; Tue, 30 Dec 2008 08:55:04 -0500 Received: from [199.232.76.173] (port=40671 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LHf3k-00048j-Fq for qemu-devel@nongnu.org; Tue, 30 Dec 2008 08:55:00 -0500 Received: from mx2.redhat.com ([66.187.237.31]:37144) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LHf3j-0006Z4-Vk for qemu-devel@nongnu.org; Tue, 30 Dec 2008 08:55:00 -0500 Message-ID: <495A282D.20809@redhat.com> Date: Tue, 30 Dec 2008 15:54:53 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1230575362-14485-1-git-send-email-glommer@redhat.com> <18777.63215.125693.799799@mariner.uk.xensource.com> In-Reply-To: <18777.63215.125693.799799@mariner.uk.xensource.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] hook cpu running at a higher level. Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ian Jackson Cc: Glauber Costa , qemu-devel@nongnu.org, kvm@vger.kernel.org, stefano.stabellini@eu.citrix.com Ian Jackson wrote: > The Xen qemu process runs only in one thread which is fine because it > doesn't need to be involved with actual processor execution. In > theory parallel execution (in different threads and thus on different > physical cpus) of IO emulations requested by different guest vcpus > might make some small performance difference but I doubt it would be > worth our while. So I think the Xen setup will still from qemu's > point of view look like a single vcpu no matter how many vcpus the > guest aactually has. > I thing it makes sense for you to have multiple vcpus -- that is multiple CPUState objects. You can still have just one thread (which would be the iothread in kvm's terminology). So: tcg - multiplexes all vcpus and io on one thread kvm - iothread + per-vcpu thread xen - iothread, vcpus scheduled by hypervisor tcg also ought to move to an iothread model, so it can take advantage of multicore for things like display updates. For x86-on-x86, it may even be possible to have vcpus running in parallel (with some kind of shared/exclusive lock on softmmu). -- error compiling committee.c: too many arguments to function