[Top][All Lists]

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

[Qemu-devel] Re: Re: Killing KQEMU

From: Chris Frey
Subject: [Qemu-devel] Re: Re: Killing KQEMU
Date: Wed, 3 Jun 2009 17:50:35 -0400
User-agent: Mutt/1.4.1i

On Tue, Jun 02, 2009 at 11:24:11PM +0300, Avi Kivity wrote:
> 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.

Even if I were to fix kqemu to support such guests, I'd have no way to
test it, with test machine specs like that.

People say on this list that nobody wants to write for old hardware, but
kernel developers (and apparently QEMU developers) are so far ahead of
the curve that they forget that a system with 1GB of RAM may be someone's
most powerful machine.

Someone with 128GB in their machine obviously doesn't need to care about
a minor speed boost from kqemu.  It's slower than their native hardware.

> If you're stepping up I can point out the problems I'm aware of.

I'm most interested in easing the pain of keeping kqemu alive.  It seems
like valuable tech that should not be thrown away just yet.

What can I, a non-expert, do to help ease the pain that does not involve
a rewrite or a porting to KVM?  I'm very competent in C and have hacked
the kernel a bit, but QEMU is new territory.

> >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.

Likely beyond my abilities at the moment.

My first step would be to learn how to debug hangs caused by kqemu and
submit patches to fix those bugs.  Any pointers to documentation you can

I see this link:

I'm hoping there's more.

- Chris

reply via email to

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