|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] Unmaintained QEMU builds |
Date: | Sun, 05 Sep 2010 17:46:46 +0300 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100806 Fedora/3.1.2-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.2 |
On 09/05/2010 05:40 PM, Blue Swirl wrote:
On Sun, Sep 5, 2010 at 2:17 PM, Avi Kivity<address@hidden> 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
[Prev in Thread] | Current Thread | [Next in Thread] |