From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LVT4t-0006yN-Js for qemu-devel@nongnu.org; Fri, 06 Feb 2009 10:57:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LVT4s-0006xl-1c for qemu-devel@nongnu.org; Fri, 06 Feb 2009 10:57:15 -0500 Received: from [199.232.76.173] (port=42830 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LVT4r-0006xg-Tf for qemu-devel@nongnu.org; Fri, 06 Feb 2009 10:57:13 -0500 Received: from mr01.hansenet.de ([213.191.74.10]:60253) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LVT4r-0004TM-CA for qemu-devel@nongnu.org; Fri, 06 Feb 2009 10:57:13 -0500 Received: from exactcode.de (85.183.32.143) by mr01.hansenet.de (7.3.132) id 4967D25500306809 for qemu-devel@nongnu.org; Fri, 6 Feb 2009 16:57:09 +0100 Received: from [192.168.2.173] (helo=[192.168.2.173]) by exactcode.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1LVT4g-0001NO-Hw for qemu-devel@nongnu.org; Fri, 06 Feb 2009 15:57:08 +0000 Message-ID: <498C5DCC.3060106@exactcode.de> Date: Fri, 06 Feb 2009 16:57:00 +0100 From: =?ISO-8859-1?Q?Ren=E9_Rebe?= MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Cutting a new QEMU release References: <1233825194.6637.4.camel@ecrins.fosdick.home.net> <498AF6FC.90803@codemonkey.ws> <200902050936.49909.rickv@hobi.com> <200902051627.21972.paul@codesourcery.com> <498B380E.5090603@codemonkey.ws> <1233917676.6637.39.camel@ecrins.fosdick.home.net> In-Reply-To: <1233917676.6637.39.camel@ecrins.fosdick.home.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: Quoted-Printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi, Steve Fosdick wrote: > On Thu, 2009-02-05 at 13:03 -0600, Anthony Liguori wrote: > > =20 >> Personally, I'd prefer that it lived outside of the QEMU tree. It is=20 >> never going to go into upstream Linux and it's not something that I=20 >> think is worth supporting. >> =20 > > Does anyone here have any stats on what people are using QEMU for? > > I ask this because I suspect a significant use case is running an x86 > guest on an x86 host and, at the moment, the only way to get reasonable > performance on a non virtualisation-enhanced CPU seems to be to use > kqmeu. > > Now, I can understand the developers of kvm only supporting the > virtualisation-enhanced CPUs because, looking to the future they will b= e > common. I suspect at the moment though there are plenty of people > running VMs on older hardware. > > I can also see that if it would take major refactoring to get kqemu int= o > the main kernal tree it is probably not worth the efforts as, by the > time that work is complete the ratio virtualisation-enhanced CPUs to > older, non virtualisation-enhanced CPUs would be higher. > > To my mind mind, what would be good right now is if someone (or some > people) understands kqemu well enough that, if kernel changes break it, > it can be fixed, not forever but until more people have > virtualisation-enhanced CPUs and can use KVM instead. > =20 Indeed. Though I used KVM for the past months to do Linux development and system testing / integration I had a use case for kqemu (non-VT CPU) just this week and was surprised to find quite "old" kqemu release just=20 build and work for booth 2.6.26 and 2.6.28. And so far there was no problem wit= h it. While I have no problem having it long time ported to the KVM interface, just declaring some quite useful and functional piece of open source work obsolete and unsupported quite drastic. This work should be not be lost so easily. When kqemu is supposed to be gotten upstream the question remains what to do with the freebsd, windows, solaris, etc. glue code. If I would know more of the internals of kqemu I would even volunteer to maintain it - however, I just took the first look at it yesterday which d= oes not really qualify to maintain it just yet. Though I would work on gettin= g it adapted on future kernel changes, and/or even hunt a bug if it starts crashing in one or another scenario for me (but right now I have to hunt some crashing with 32bit host KVM for a start). Yours, --=20 Ren=E9 Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name