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: Mark Williamson
Subject: Re: [Qemu-devel] About qemu emulation speed (a question) and supported OS
Date: Wed, 14 Sep 2005 04:48:24 +0100
User-agent: KMail/1.8

> >No, I got the impression that Fabrice was taking about virtualization the
> > way VMware, old plex86, and vmbear (new FOSS x86 virtualizer in the
> > works) do it.
>
> 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).  Do you have

Well, VMware does manage direct execution of some kernel code, I believe.  
VMware's real super-cunningness is doing this as much as they can, instead of 
emulating all the stuff.  That said, I think with suitable optimisations 
emulating all the kernel code could be acceptable.

The unfortunate thing is that the guest can still tell it's in a VMware 
machine (I'm not clear how) so it's not really *full* virtualisation, it's 
just about epsilon away from it :-)  VT / SVM will solve this properly.

> 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.

The original L4 port of Linux was pretty hard-core stuff.  I understand later 
L4 developments made native ports easier.  The afterburner stuff seems to be 
the next generation of coolness!

The afterburning is really neat stuff :-)  You can use one kernel for native, 
L4 guest and Xen guest.  The kernel actually does some of the virtualisation 
work itself by doing (tasteful levels of) self-rewriting / device emulation 
on its own.  You can run normal device drivers, etc.  This has to be assisted 
by some compiler tool-chain stuff that allows the runtime "wedge" to do its 
job.

They have a (crazy but cool) idea that they'll one day be able to live-migrate 
(i.e. without more than a few hundred ms downtime) virtual machines between 
L4 hypervisors and Xen hypervisors.

Cheers,
Mark

> >>FWIW, Xen is already using QEMU in this way.  It would be very neat to
> >>see this technique applied to a Type II VMM.
> >
> >Do you have any details on this?
>
> Mark did a really good job of summarizing the current architecture.
>
> Regards,
>
> Anthony Liguori
>
> >>Regards,
> >>
> >>Anthony Liguori
> >>
> >>
> >>_______________________________________________
> >>Qemu-devel mailing list
> >>address@hidden
> >>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
> _______________________________________________
> Qemu-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qemu-devel




reply via email to

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