From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LHcsU-0006fv-3b for qemu-devel@nongnu.org; Tue, 30 Dec 2008 06:35:14 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LHcsS-0006fb-EU for qemu-devel@nongnu.org; Tue, 30 Dec 2008 06:35:12 -0500 Received: from [199.232.76.173] (port=37311 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LHcsS-0006fY-50 for qemu-devel@nongnu.org; Tue, 30 Dec 2008 06:35:12 -0500 Received: from qw-out-1920.google.com ([74.125.92.146]:15034) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LHcsR-00075k-Nl for qemu-devel@nongnu.org; Tue, 30 Dec 2008 06:35:11 -0500 Received: by qw-out-1920.google.com with SMTP id 5so2358643qwc.4 for ; Tue, 30 Dec 2008 03:35:07 -0800 (PST) Message-ID: <5d6222a80812300335kacdf330pfe4a51e59e0e203e@mail.gmail.com> Date: Tue, 30 Dec 2008 09:35:06 -0200 From: "Glauber Costa" Subject: Re: [Qemu-devel] Re: [PATCH] hook cpu running at a higher level. In-Reply-To: <18777.63215.125693.799799@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1230575362-14485-1-git-send-email-glommer@redhat.com> <18777.63215.125693.799799@mariner.uk.xensource.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: Glauber Costa , avi@redhat.com, kvm@vger.kernel.org, stefano.stabellini@eu.citrix.com On Tue, Dec 30, 2008 at 8:24 AM, Ian Jackson > 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. Is it one vcpu or various in lockstep ? If you have only one vcpu, your main loop can be even simpler than qemu's, which holds them all in a for loop. > The way we have approached these problems in the Xen tree is to supply > an alternative implementation of (say) main_loop and arrange for the > standard one not to be compiled. Is it the intent to make kvm a > run-time selectable option ? It seems to me that that given that we > already have different qemu builds for all of the various target > (guest) cpu architectures, it might be simpler to continue that > approach. With a bit of judicious movement of code into appropriate > files, this will avoid the need for ifs and ifdefs. > I believe the idea here is to bring up something close to the accel patches (this one, plus the ones for memory_rw and registered I already posted). So you would not see this, but simply "cpu_main_loop()", that would call into the right thing, no matter what it is. This allow for both runtime and compile time selection of what you're running. -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act."