[Qemu-devel] Re: Killing KQEMU

[Chris Frey]

On Tue, Jun 02, 2009 at 01:54:30PM +0100, Paul Brook wrote:
> osdep.c:/* FIXME: This file should be target independent. However it has kqemu
> vl.c:    /* FIXME: This is a nasty hack because kqemu can't cope with dynamic
> cpu-common.h: #ifdef CONFIG_KQEMU /* FIXME: This is wrong.  */
> exec.c: #elif defined(TARGET_X86_64) && !defined(CONFIG_KQEMU)

These are fairly small annoyances, no?  I'm assuming they are, since they
exist at all, considering the frustration evident in:


> Or let me put it another way: At some point I'll get fed up of the
> limitations that kqemu currently imposes, and deliberately break it.

I would hope that anyone who deliberately breaks kqemu support would be
kind enough to post that fact to the mailing list, with a description of
what's broken and why, so that others may step up to the plate and fix it.

Breaking something deliberately and quietly, only to use it later as an
excuse to remove the feature could be seen as anti-social.


> If it remains broken then it will be removed. You get to decide whether
> you want to fix kqemu, start again from scratch (probably enhancing KVM),
> or keep using old versions of qemu.

The KVM website (http://www.linux-kvm.org/) states very clearly that its
goal is for systems that support virtualization extensions.  Is it possible
to write a pluggable KQEMU backend to KVM, for old systems, that QEMU could
use blindly as a native KVM system?  How open are the KVM developers to API
changes imposed by KQEMU-like functionality?


> As I've said before, if you're serious about maintaining kqemu you probably 
> need to get it integrated into mainstream kernels. Without this a large 
> portion of the relevant communities simply aren't going to care.

According to other threads on this list, it would appear that getting
KQEMU into the kernel is often thought of as impossible, or "would never
happen."  So this isn't really a solution either.

- Chris