Re: [Qemu-devel] Unmaintained QEMU builds

[Avi Kivity]

 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