public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Markus Armbruster <armbru@redhat.com>
Cc: kvm@vger.kernel.org, "Daniel P. Berrange" <berrange@redhat.com>,
	"Richard W. M. Jones" <rjones@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [PATCH] qemu-kvm: Switch to upstream -enable-kvm semantics
Date: Wed, 15 Dec 2010 11:31:41 -0600	[thread overview]
Message-ID: <4D08FB7D.2010702@codemonkey.ws> (raw)
In-Reply-To: <m3mxo7ox0v.fsf@blackfin.pond.sub.org>

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<armbru@redhat.com>
>    

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.

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).  Adding an alias for 'kvmpc' upstream and qemu-kvm and 
making qemu-kvm default to 'kvmpc' would be helpful for management tools 
too.

Regards,

Anthony Liguori

> ---
>   vl.c |   10 +---------
>   1 files changed, 1 insertions(+), 9 deletions(-)
>
> diff --git a/vl.c b/vl.c
> index e3c8919..87e88c2 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -247,7 +247,7 @@ static void *boot_set_opaque;
>   static NotifierList exit_notifiers =
>       NOTIFIER_LIST_INITIALIZER(exit_notifiers);
>
> -int kvm_allowed = 1;
> +int kvm_allowed = 0;
>   uint32_t xen_domid;
>   enum xen_mode xen_mode = XEN_EMULATE;
>
> @@ -2436,10 +2436,8 @@ int main(int argc, char **argv, char **envp)
>               case QEMU_OPTION_smbios:
>                   do_smbios_option(optarg);
>                   break;
> -#ifdef OBSOLETE_KVM_IMPL
>               case QEMU_OPTION_enable_kvm:
>                   kvm_allowed = 1;
> -#endif
>                   break;
>   	    case QEMU_OPTION_no_kvm:
>   		kvm_allowed = 0;
> @@ -2789,18 +2787,12 @@ int main(int argc, char **argv, char **envp)
>       if (kvm_allowed) {
>           int ret = kvm_init(smp_cpus);
>           if (ret<  0) {
> -#if defined(OBSOLETE_KVM_IMPL) || defined(CONFIG_NO_CPU_EMULATION)
>               if (!kvm_available()) {
>                   printf("KVM not supported for this target\n");
>               } else {
>                   fprintf(stderr, "failed to initialize KVM: %s\n", strerror(-ret));
>               }
>               exit(1);
> -#endif
> -#ifdef CONFIG_KVM
> -            fprintf(stderr, "Could not initialize KVM, will disable KVM support\n");
> -            kvm_allowed = 0;
> -#endif
>           }
>       }
>
>    


  reply	other threads:[~2010-12-15 17:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-15 15:50 [PATCH] qemu-kvm: Switch to upstream -enable-kvm semantics Markus Armbruster
2010-12-15 17:31 ` Anthony Liguori [this message]
2010-12-15 17:57   ` Markus Armbruster
2010-12-21 15:16     ` Avi Kivity
2010-12-21 15:41       ` Markus Armbruster
2010-12-21 15:48         ` Avi Kivity
2010-12-21 16:05           ` Markus Armbruster
2010-12-21 16:00         ` Richard W.M. Jones
2010-12-21 16:02           ` Richard W.M. Jones
2010-12-21 16:07           ` Markus Armbruster
2010-12-21 16:56             ` [Qemu-devel] " Anthony Liguori
2010-12-21 17:25               ` Alexander Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D08FB7D.2010702@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox