[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Unmaintained QEMU builds

From: Avi Kivity
Subject: Re: [Qemu-devel] Unmaintained QEMU builds
Date: Sun, 05 Sep 2010 18:57:22 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100806 Fedora/3.1.2-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.2

 On 09/05/2010 06:44 PM, Andreas Färber wrote:
Am 05.09.2010 um 16:17 schrieb Avi Kivity:

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.

I believe I already inquired about this when kqemu was dropped: KVM is GPL'ed iiuc. May we use it as a kernel extension with proprietary Mac OS X at all then?

No idea.

I thought there was some controversy on whether runtime-linking GPL modules to a closed-source kernel constitutes a GPL violation or not. (it would be news to me if Darwin/x86 was ever supported by kqemu) Having kqemu running as a userland service process (?) on Windows seems unproblematic by comparison.

These things want to run in the kernel (or did you mean a kernel driver providing services to userland?)

Don't know about the BSDs or how this would fit with OpenSolaris' CDDL. On Haiku new kernel code would probably be preferred under MIT/X11 License.

In either case, I'm not aware of a clear documentation of what exactly is required to implement on the kernel side to replace kqemu or to provide a completely compatible implementation. It seems like a moving target.

You can pick any recent snapshot and implement its interface. We don't force to upgrade their kernel as we go along.

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.

This discussion was about non-Linux only. We can hardly call the Linux build unmaintained! :)

Yeah - I though it diverged to whether we ship a bundled GUI or not - without that, performance doesn't really matter for non-Linux.

error compiling committee.c: too many arguments to function

reply via email to

[Prev in Thread] Current Thread [Next in Thread]