From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EFXU0-0001DL-6z for qemu-devel@nongnu.org; Wed, 14 Sep 2005 09:39:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EFXTu-0001A7-CO for qemu-devel@nongnu.org; Wed, 14 Sep 2005 09:39:22 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EFXTt-00019K-PL for qemu-devel@nongnu.org; Wed, 14 Sep 2005 09:39:21 -0400 Received: from [128.8.10.163] (helo=po1.wam.umd.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EFXSH-0006TW-98 for qemu-devel@nongnu.org; Wed, 14 Sep 2005 09:37:41 -0400 Received: from jbrown.mylinuxbox.org (jma-box.student.umd.edu [129.2.253.219]) by po1.wam.umd.edu (8.12.10/8.12.10) with ESMTP id j8EDbcxA018182 for ; Wed, 14 Sep 2005 09:37:38 -0400 (EDT) Date: Wed, 14 Sep 2005 09:37:34 -0400 From: "Jim C. Brown" Subject: Re: [Qemu-devel] About qemu emulation speed (a question) and supported OS Message-ID: <20050914133733.GA6052@jbrown.mylinuxbox.org> References: <1dc7f0e3050913053635cd61af@mail.gmail.com> <20050913133813.GA28356@jbrown.mylinuxbox.org> <4326E903.7070900@us.ibm.com> <20050913214856.GA31111@jbrown.mylinuxbox.org> <43278F61.8060103@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43278F61.8060103@us.ibm.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 On Tue, Sep 13, 2005 at 09:48:01PM -0500, Anthony Liguori wrote: > Jim C. Brown wrote: > > The x86 cannot be "virtualized" in the Popek/Goldberg sense, so there's > a couple of fast emulation techniques that are possible. Other than a > hand coded dynamic translator, I reckon qemu + kqemu is about as good as > it can get (unless I'm missing something here). qvm86 only virtualizes ring3 code. It doesn't handle ring 0 (e.g. kernel) at all. VMware handles kernel code. You are right that x86 code can't be 100% virtualized (even at the userland level) but VMware uses a lot of nasty disgusting tricks in order to work around them. (For example, playing with shadow pagetables so that a page of modified code is run but if the code tries to inspect itself it sees another (unexecuted) page that contains the original code.) Basically the original code is 'fixed' so it runs in ring 3, but this is still faster than translation. > Do you have > Do I have what? > There are a couple of interesting paravirtualization techniques too. > There's the Xen approach (really fast, but very invasive), the L4ka > afterburning (theoritically close to as fast, but less invasive), and > then of course the extremes like UML. > Not familar with L4ka. I don't believe that UML does virtualization, it simply runs linux code 'as is' but intercepts calls to the kernel. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection.