From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MC6fm-0000zq-A3 for qemu-devel@nongnu.org; Thu, 04 Jun 2009 02:43:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MC6fN-0000lK-7w for qemu-devel@nongnu.org; Thu, 04 Jun 2009 02:43:16 -0400 Received: from [199.232.76.173] (port=42027 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MC6fM-0000hB-L6 for qemu-devel@nongnu.org; Thu, 04 Jun 2009 02:43:08 -0400 Received: from mx2.redhat.com ([66.187.237.31]:45022) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MC6VF-0004Cq-Mb for qemu-devel@nongnu.org; Thu, 04 Jun 2009 02:32:42 -0400 Message-ID: <4A276A0E.9020709@redhat.com> Date: Thu, 04 Jun 2009 09:30:38 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20090602035217.GA16574@foursquare.net> <200906012345.18729.rickv@hobi.com> <200906021354.31637.paul@codesourcery.com> <20090602200918.GA27850@foursquare.net> <4A258A6B.4050704@redhat.com> <20090603215035.GA23831@foursquare.net> In-Reply-To: <20090603215035.GA23831@foursquare.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: Killing KQEMU List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chris Frey Cc: Paul Brook , qemu-devel@nongnu.org Chris Frey wrote: > 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. > You don't need to make kqemu run large guests, just stop it from preventing qemu and qemu/kvm from running large guests. It's perfectly reasonable for kqemu to have some limitations. >> 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. > Start by finding out why kqemu insists on 32-bit page descriptors, and increase it to 64 bits. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.