qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] About qemu emulation speed (a question) and supported O


From: Jim C. Brown
Subject: Re: [Qemu-devel] About qemu emulation speed (a question) and supported OS
Date: Wed, 14 Sep 2005 09:37:34 -0400
User-agent: Mutt/1.4i

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]