qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: Cutting a new QEMU release


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: Cutting a new QEMU release
Date: Sat, 07 Feb 2009 17:46:37 -0600
User-agent: Thunderbird 2.0.0.19 (X11/20090105)

Jamie Lokier wrote:
Anthony Liguori wrote:
Yes, it's unfortunate how its history worked out. On the face of it,
it looks like Fabrice was hoping for someone to pay for it.  Maybe
they did.  I remember a vague murmur of an attempt to make an open
source replacement for kqemu when it was still binary-only; that
didn't go anywhere as far as I remember.

Anthony: If one or more maintainers were to step up, perhaps even
begin adapting the kqemu interface to kvm's, would you be interested
in folding it in the main qemu/kvm project as an official feature?

Actions speak louder than words. All it takes is for someone to setup a tree somewhere with kqemu in it, and start working on it and merging patches. Once that happens, we can discuss the long term future wrt KVM and QEMU. Otherwise, it's just pontificating here. Merging into Linux proper is going to be a lot of work.

I strongly suspect you won't see anyone step up. From a developer perspective, it's a case of diminishing returns. The more work you put into it, the less useful it is to people. Every day that goes buy, the potential audience grows smaller. Furthermore, the barrier to entry for someone to get a better solution is (i.e. KVM) is rather small. Just buy a new CPU.

I think the only way it would prove useful to maintain is if some developer either has a deep desire to mess around with this kind of stuff or has a large customer base with pre-VT/SVM hardware that they wish to support. So far, no such developer has proven to exist. Recall, even when kqemu was the only solution (but closed source), there wasn't really anyone interested/willing to maintain qvm86.

N.B. KVM and kqemu are not equal solutions. Even at it's best, kqemu is going to be significantly slower than KVM in most cases. When dealing with more modern CPUs (Barcelonas and Core i7s), the difference is going to be extremely high.

Regards,

Anthony Liguori

Straw poll: who here's interested in maintaining kqemu?

I have very little time, but plenty of x86 intimate knowledge and
kernel knowledge, and have used kqemu occasionally.  I can offer my
hand as "interested a bit, not by myself".

(Also, perhaps some of the Windows / other kqemu bits might be useful
in porting kvm to Windows.  Now that we have nested kvm, those of us
who never run a native Windows host can think about testing such a thing ;-)

-- Jamie







reply via email to

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