From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] hook cpu running at a higher level. Date: Tue, 30 Dec 2008 15:54:53 +0200 Message-ID: <495A282D.20809@redhat.com> References: <1230575362-14485-1-git-send-email-glommer@redhat.com> <18777.63215.125693.799799@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Glauber Costa , qemu-devel@nongnu.org, kvm@vger.kernel.org, stefano.stabellini@eu.citrix.com To: Ian Jackson Return-path: Received: from mx2.redhat.com ([66.187.237.31]:48854 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753271AbYL3NzA (ORCPT ); Tue, 30 Dec 2008 08:55:00 -0500 In-Reply-To: <18777.63215.125693.799799@mariner.uk.xensource.com> Sender: kvm-owner@vger.kernel.org List-ID: 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