From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EZ0Wx-00035e-Cl for qemu-devel@nongnu.org; Mon, 07 Nov 2005 01:30:59 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EZ0Wv-00035S-Hi for qemu-devel@nongnu.org; Mon, 07 Nov 2005 01:30:58 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EZ0Wv-00035P-DB for qemu-devel@nongnu.org; Mon, 07 Nov 2005 01:30:57 -0500 Received: from [32.97.110.149] (helo=e31.co.us.ibm.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EZ0Wv-00025N-Ce for qemu-devel@nongnu.org; Mon, 07 Nov 2005 01:30:57 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jA76UtDD004490 for ; Mon, 7 Nov 2005 01:30:56 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jA76UtWP059220 for ; Sun, 6 Nov 2005 23:30:55 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jA76UtR9021486 for ; Sun, 6 Nov 2005 23:30:55 -0700 Message-ID: <436EF496.8040306@us.ibm.com> Date: Mon, 07 Nov 2005 00:30:46 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Qemu and (Pacifica | Vanderpool) References: <200511061019.18720.dfeustel@verizon.net> <200511061533.13098.paul@codesourcery.com> <436EA681.1010302@us.ibm.com> <20051107055652.GA26645@jbrown.mylinuxbox.org> In-Reply-To: <20051107055652.GA26645@jbrown.mylinuxbox.org> 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: "Jim C. Brown" Cc: qemu-devel@nongnu.org Jim C. Brown wrote: >>VT/SVM will definitely improve the performance of kqemu/qvm86. >> >> > >VT/SVM won't actually help them that much in the current case, assuming that my >understanding is correct. They can only make the userland bits a little >faster, and kqemu/qvm86 don't support running kernel code (where the real gains >would be realized). > VT/SVM allows you to run kernel code unmodified and without binary translation on bare metal. >They could be extended to take over both userland and kernel code easily though. >(In which case the user space qemu would provide only the system emulation >bits - there'd no longer be any emulation of the guest cpu). > Yup. >I believe that >there are plans to extend kqemu to be able to do this at some point. But at >that point I'd hesitate to call the combination "QEMU", since there would be >nothing of the original qemu left (for the record this considered of the >dynamic translator/JIT and the qemu-user code). > > kqemu would have to take advantage of VT/SVM to be able to run kernel code. There's an excellent paper (that I referenced in my previous note) that explains why this is the case. >Agreed. Of course, since Xen runs on the bare metal, one would expect that it >would have better performance than qemu anyways (though if qemu's io model is >used, that is not going to be true for the obvious reasons). If ease of >installation is more important than performance, qemu is less invasive. I guess >that can be considered a tradeoff. > > Yeah, I think that's the basic trade-off. >I doubt qemu + kqemu/qvm86 is a pure Type II anyways, since it modifies the >host operating system. And from my understanding of qvm86, the userland code >is essentially run directly by qvm86 directly on the bare hardware, since the >only parts of the host kernel that are involved are the parts that tell the >kernel to leave that code alone. Modifying the accelerators so they handle >running of all the guest code moves even farther away from this. > > The original Popek/Goldberg paper puts a set of requirements on the host Operating System such that one can implement a Type II VMM. You can think of kqemu/qvm86 as extending the host operating system to satisfy the Type II requirements. Regards, Anthony Liguori >-- >Infinite complexity begets infinite beauty. >Infinite precision begets infinite perfection. > > >