From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: [PATCH] qemu-kvm: Switch to upstream -enable-kvm semantics Date: Wed, 15 Dec 2010 18:57:06 +0100 Message-ID: References: <4D08FB7D.2010702@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, "Daniel P. Berrange" , "Richard W. M. Jones" , qemu-devel To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:22572 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751226Ab0LOR5W (ORCPT ); Wed, 15 Dec 2010 12:57:22 -0500 In-Reply-To: <4D08FB7D.2010702@codemonkey.ws> (Anthony Liguori's message of "Wed, 15 Dec 2010 11:31:41 -0600") Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori writes: > On 12/15/2010 09:50 AM, Markus Armbruster wrote: >> We currently enable KVM by default, and when it's not available, we >> print a message and fall back to TCG. Option -enable-kvm is ignored. >> Option -no-kvm suppresses KVM. >> >> Upstream works differently: KVM is off by default, -enable-kvm >> switches it on. -enable-kvm terminates the process unsuccessfully if >> KVM is not available. >> >> upstream qemu | default |-enable-kvm >> ----------------+-----------+----------- >> KVM available | disabled | enabled >> KVM unavailable | disabled | fail >> >> qemu-kvm | default |-enable-kvm >> ----------------+-----------+----------- >> KVM available | enabled* | enabled >> KVM unavailable | disabled | disabled* >> >> * differs from upstream >> >> Users of qemu and qemu-kvm need to be aware of these differences to >> enable / disable use of KVM reliably. This is bothersome. >> >> Consider -enable-kvm when KVM is unavailable: If the user expects >> qemu-kvm behavior (fall back), but qemu fails, he'll likely be >> surprised and unhappy. If the user expects upstream behavior (fail), >> but qemu-kvm falls back to TCG, the guest runs slow as molasses, and >> the user will likely be confused and unhappy (unless he spots and >> understands the "disable KVM" message). >> >> Switch to upstream semantics: KVM off by default, -enable-kvm switches >> it on, and when it can't, it's fatal. >> >> Having to enable KVM explicitly is annoying, but the proper place to >> address that is upstream. >> >> Signed-off-by: Markus Armbruster >> > > Backwards compatibility is going to kill us if we try to make this change. > > Current qemu-kvm behavior: > > default: -accel kvm,tcg > -no-kvm: -accel tcg > -enable-kvm: -accel kvm,tcg > > Current upstream behavior > > default: -accel tcg > -enable-kvm: -accel kvm > > I think we should tie `-accel' to the machine type. For qemu-kvm, a > different default machine type should be used than upstream qemu (it > really should be a configure switch). > > For `pc', the default `-accel' behavior should remain 'tcg'. For > kvmpc', the default `-accel' behavior should be 'kvm,tcg'. > > -no-kvm should be deprecated. -enable-kvm should also be deprecated > in favor of the `-accel' option. I'm fine with -accel and deprecating the old options. But until we have that: > In the short term, it would be a good idea to modify qemu-kvm to > switch the -enable-kvm semantics to match upstream (fail if KVM isn't > available). That's what my patch does. Additionally, it changes the default to match upstream: KVM disabled. What do you want changed in my patch? > Adding an alias for 'kvmpc' upstream and qemu-kvm and > making qemu-kvm default to 'kvmpc' would be helpful for management > tools too. That would address "Having to enable KVM explicitly is annoying".