From mboxrd@z Thu Jan  1 00:00:00 1970
From: Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] [PATCH] kvm: Set default accelerator to "kvm" if
 the host supports it
Date: Tue, 2 Oct 2012 10:15:02 +0200
Message-ID: <20121002081502.GI4623@ohm.aurel32.net>
References: <50694EC1.8060006@siemens.com>
 <20121001093102.GA14797@amt.cnet>
 <50696E9E.7030302@siemens.com>
 <87zk468h3y.fsf@codemonkey.ws>
 <50699CDC.1010604@redhat.com>
 <87wqzap9ui.fsf@codemonkey.ws>
 <5069A9DF.4040606@siemens.com>
 <5069C814.7010201@suse.de>
 <20121001164730.GC15554@redhat.com>
 <87zk4571vf.fsf@blackfin.pond.sub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: "Daniel P. Berrange" <berrange@redhat.com>,
	kvm <kvm@vger.kernel.org>, Scott Moser <smoser@ubuntu.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Michael Tokarev <mjt@tls.msk.ru>,
	qemu-devel <qemu-devel@nongnu.org>,
	Bruce Rogers <brogers@suse.com>, Avi Kivity <avi@redhat.com>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Cole Robinson <crobinso@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andreas =?iso-8859-15?Q?F=E4rber?= <afaerber@suse.de>
To: Markus Armbruster <armbru@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from hall.aurel32.net ([88.191.126.93]:36931 "EHLO hall.aurel32.net"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750792Ab2JBJlb (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 2 Oct 2012 05:41:31 -0400
Content-Disposition: inline
In-Reply-To: <87zk4571vf.fsf@blackfin.pond.sub.org>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Tue, Oct 02, 2012 at 09:46:12AM +0200, Markus Armbruster wrote:
> "Daniel P. Berrange" <berrange@redhat.com> writes:
>=20
> > On Mon, Oct 01, 2012 at 06:43:00PM +0200, Andreas F=E4rber wrote:
> >> Hello Jan,
> >>=20
> >> Am 01.10.2012 16:34, schrieb Jan Kiszka:
> >> > If we built a target for a host that supports KVM in principle, =
set the
> >> > default accelerator to KVM as well. This also means the start of=
 QEMU
> >> > will fail to start if KVM support turns out to be unavailable at
> >> > runtime.
> >>=20
> >> From a distro point of view this of course means that we will buil=
d
> >> against KVM and that the new KVM default will start to fail for us=
ers on
> >> very old hardware. Can't we do a runtime check to select the defau=
lt?
> >
> > NB, this is *not* only about old hardware. There are plenty of user=
s who
> > use QEMU inside VMs. One very common usage I know of is image build=
ing
> > tools which are run inside Amazon VMs, using libguestfs & QEMU.
> >
> > IMHO, default to KVM, fallback to TCG is the most friendly default
> > behaviour.
>=20
> Friendly perhaps, generating an infinite series of questions "why is =
my
> guest slow as molasses?" certainly.
>=20
> And for each instance of the question, there's an unknown number of
> users who give QEMU a quick try, screw up KVM unknowingly, observe th=
e
> glacial speed, and conclude it's crap.
>=20

That's why it should not fallback silently to TCG, but warn the user
about that.

On the other hand, on a machine without KVM support (which might just b=
e
because of local policy admin policy which doesn't provide access the=20
/dev/kvm, nested virtualization, etc.), if QEMU fails to start (while
previous versions were working), the user can conclude that QEMU is
crap.

--=20
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net