qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Jim C. Brown" <jma5@umd.edu>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] About qemu emulation speed (a question)	and	supported OS
Date: Wed, 14 Sep 2005 09:37:34 -0400	[thread overview]
Message-ID: <20050914133733.GA6052@jbrown.mylinuxbox.org> (raw)
In-Reply-To: <43278F61.8060103@us.ibm.com>

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.

  parent reply	other threads:[~2005-09-14 13:39 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-13 12:36 [Qemu-devel] About qemu emulation speed (a question) and supported OS Alexandre Leclerc
2005-09-13 13:08 ` Adrian Smarzewski
2005-09-13 18:02   ` Alexandre Leclerc
2005-09-13 13:38 ` Jim C. Brown
2005-09-13 14:58   ` Anthony Liguori
2005-09-13 21:48     ` Jim C. Brown
2005-09-14  0:18       ` Mark Williamson
2005-09-14  2:48       ` Anthony Liguori
2005-09-14  3:48         ` Mark Williamson
2005-09-14  4:27           ` Anthony Liguori
2005-09-14  4:58             ` Mike Swanson
2005-09-14 13:39             ` Jim C. Brown
2005-09-14 18:46               ` Anthony Liguori
2005-09-14 22:42                 ` Jim C. Brown
2005-09-14 13:37         ` Jim C. Brown [this message]
2005-09-14 15:47           ` Henrik Nordstrom
2005-09-14 17:53             ` Mark Williamson
2005-09-14 17:18           ` John R. Hogerhuis
2005-09-14 22:34             ` Jim C. Brown
2005-09-14 17:46           ` Mark Williamson
2005-09-15 21:26           ` Karl Magdsick
2005-09-15 23:24             ` Mark Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050914133733.GA6052@jbrown.mylinuxbox.org \
    --to=jma5@umd.edu \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).