Re: [Qemu-devel] Qemu and (Pacifica | Vanderpool)

["Jim C. Brown" <jma5@umd.edu>]

On Sun, Nov 06, 2005 at 06:57:37PM -0600, Anthony Liguori wrote:
> >qemu is an emulator, not a virtualizer, so these extensions don't really 
> >help.
> > 
> >
> Not quite.
> 
> qemu is technically a JIT.  kqemu/qvm86 are virtualizers.  Bochs is an 
> actual emulator.
> 

VT/SVM won't help the JIT part of qemu. And kqemu/qvm86 are optional.

> VT/SVM will definitely improve the performance of kqemu/qvm86. 

VT/SVM won't actually help them that much in the current case, assuming that my
understanding is correct. They can only make the userland bits a little
faster, and kqemu/qvm86 don't support running kernel code (where the real gains
would be realized). The JIT still handles that, so there is still an emulated
cpu.

They could be extended to take over both userland and kernel code easily though.
(In which case the user space qemu would provide only the system emulation
bits - there'd no longer be any emulation of the guest cpu). I believe that
there are plans to extend kqemu to be able to do this at some point. But at
that point I'd hesitate to call the combination "QEMU", since there would be
nothing of the original qemu left (for the record this considered of the
dynamic translator/JIT and the qemu-user code).

> >You may want to look at Xen (www.xensource.com), which already supports 
> >these.
> > 
> >
> Xen is a Type I VMM, QEmu is a Type II.  They aren't interchangable.
> 

Agreed. Of course, since Xen runs on the bare metal, one would expect that it
would have better performance than qemu anyways (though if qemu's io model is
used, that is not going to be true for the obvious reasons). If ease of
installation is more important than performance, qemu is less invasive. I guess
that can be considered a tradeoff.

I doubt qemu + kqemu/qvm86 is a pure Type II anyways, since it modifies the
host operating system. And from my understanding of qvm86, the userland code
is essentially run directly by qvm86 directly on the bare hardware, since the
only parts of the host kernel that are involved are the parts that tell the
kernel to leave that code alone. Modifying the accelerators so they handle
running of all the guest code moves even farther away from this.

--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.