On 09/05/2010 05:40 PM, Blue Swirl wrote:
On Sun, Sep 5, 2010 at 2:17 PM, Avi Kivity<a...@redhat.com> wrote:
On 09/05/2010 05:10 PM, Blue Swirl wrote:
Easy to use GUI and integration to host system are important, but
performance is also a big problem. QEMU/TCG can't compete with
alternatives that use proprietary kernel modules. Someone should
recreate kqemu by using KVM compatible interfaces.
If someone is really willing to invest the effort to do that cleanly, I am
willing to merge it into kvm. That would allow reuse of the mmu and some
other logic that got a lot of effort in kvm.
However, I doubt it is worth the effort, if anyone is interested in
performance then they'd get a cpu that supports virtualization.
That leaves non-Linux. Can qemu really compete there for x86-on-x86? I
doubt it.
Someone could also make a KVM compatible module for non-Linux hosts
with virtualization capable CPUs.
Someone actually did port kvm-17 or thereabouts to Windows.
Wouldn't that solve most performance
problems?
It would. What I doubt is that the qemu community can produce a GUI
that rivals with the commercial virtualization GUIs available for Windows.
On Linux we have the advantages of being open source and of being
integrated with the host native virtualization capabilities. On
Windows/Apple the first advantage isn't so important, and the second one
doesn't exist. So if qemu were to compete in those markets, it wouldn't
have any advantages, but many disadvantages (foremost, being way behind
on the GUI front).
--
error compiling committee.c: too many arguments to function
