|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] About qemu emulation speed (a question) and supported OS |
Date: | Tue, 13 Sep 2005 21:48:01 -0500 |
User-agent: | Mozilla Thunderbird 1.0.6 (X11/20050912) |
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). Do you haveOn Tue, Sep 13, 2005 at 09:58:11AM -0500, Anthony Liguori wrote:Jim C. Brown wrote:I reckon this means taking advantage of VT and Pacifica when they're available so the kernel code can be safely run on bare metal.Fabrice had said that he > >wants kqemu to be able to do total virtualization (both kernel and userland > >bits);basically all the translation code of qemu would be left unused but the hardware> >emulation would still be shared.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.
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.
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
[Prev in Thread] | Current Thread | [Next in Thread] |