From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MCxnY-0003x6-UT for qemu-devel@nongnu.org; Sat, 06 Jun 2009 11:27:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MCxnT-0003tX-Il for qemu-devel@nongnu.org; Sat, 06 Jun 2009 11:27:08 -0400 Received: from [199.232.76.173] (port=42931 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MCxnT-0003tK-FG for qemu-devel@nongnu.org; Sat, 06 Jun 2009 11:27:03 -0400 Received: from mx2.redhat.com ([66.187.237.31]:53580) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MCxnT-0006yt-2F for qemu-devel@nongnu.org; Sat, 06 Jun 2009 11:27:03 -0400 Date: Sat, 6 Jun 2009 18:24:52 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] Re: Killing KQEMU Message-ID: <20090606152452.GB5558@redhat.com> References: <20090602035217.GA16574@foursquare.net> <200906022130.42639.paul@codesourcery.com> <762CAA99-0A24-4A4A-94F0-7F3B2610AEC9@web.de> <200906061227.10119.paul@codesourcery.com> <971073E1-0D48-46C3-93B0-8DC3671671D5@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <971073E1-0D48-46C3-93B0-8DC3671671D5@web.de> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?utf-8?Q?F=C3=A4rber?= Cc: Chris Frey , Paul Brook , qemu-devel@nongnu.org On Sat, Jun 06, 2009 at 03:50:26PM +0200, Andreas F=C3=A4rber wrote: > > Am 06.06.2009 um 13:27 schrieb Paul Brook: > >>> A very nice use case of QEMU is that it works cross-platform, cross- >>> hardware. >> >> This actually argues against using kqemu as it only works in on =20 >> "native" >> hosts. > > Nope. It means that I can easily interchange identical VMs between =20 > accelerated (e.g. kqemu) and unaccelerated emulators. It works great, =20 > with the same command line[1], since it does not appear to change the =20 > hardware configuration [2]. > > This does not rule out KVM as future replacement, obviously, if KVM-=20 > specific things like virtio etc. do not interfere. There is nothing KVM specific in virtio. > But still dropping kqemu means having an unaccelerated emulation on =20 > those machines not capable of running KVM due to hardware, OS or KVM-=20 > versioning issues. > > Andreas > > [1] assuming no -kernel-kqemu > [2] as opposed to moving guest images between different virtualization/= =20 > emulation solutions > > -- Gleb.