Jim C. Brown wrote:
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).
VT/SVM allows you to run kernel code unmodified and without binary
translation on bare metal.
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).
Yup.
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).
kqemu would have to take advantage of VT/SVM to be able to run kernel
code. There's an excellent paper (that I referenced in my previous
note) that explains why this is the case.
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.
Yeah, I think that's the basic trade-off.
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.
The original Popek/Goldberg paper puts a set of requirements on the host
Operating System such that one can implement a Type II VMM. You can
think of kqemu/qvm86 as extending the host operating system to satisfy
the Type II requirements.
Regards,
Anthony Liguori
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
