[Top][All Lists]

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

Re: [Qemu-devel] Re: Killing KQEMU

From: Avi Kivity
Subject: Re: [Qemu-devel] Re: Killing KQEMU
Date: Tue, 02 Jun 2009 23:24:11 +0300
User-agent: Thunderbird (X11/20090320)

Chris Frey wrote:
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?

Not supporting >2GB guests is a large annoyance (very large if you have 128GB of RAM). Don't know about the others. I think kqemu also blocks memory hotplug.

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 you're stepping up I can point out the problems I'm aware of.

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?

It is possible, however it is a very difficult undertaking.

How open are the KVM developers to API
changes imposed by KQEMU-like functionality?

Clean, unintrusive patches will be accepted, if there is a commitment to maintain them.

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.

kqemu as is is probably unmergable. Your best bet is though kvm since that already has the interfaces defined and accepted (as well as large chunks of code like the mmu and x86 emulator that can be reused.

Do not meddle in the internals of kernels, for they are subtle and quick to 

reply via email to

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