From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57015) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dpruS-00074P-SA for qemu-devel@nongnu.org; Thu, 07 Sep 2017 04:11:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dpruR-0004cG-Lu for qemu-devel@nongnu.org; Thu, 07 Sep 2017 04:11:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36190) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dpruR-0004b0-D7 for qemu-devel@nongnu.org; Thu, 07 Sep 2017 04:11:35 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C34914E4F3 for ; Thu, 7 Sep 2017 08:11:33 +0000 (UTC) Date: Thu, 7 Sep 2017 10:11:31 +0200 From: Kevin Wolf Message-ID: <20170907081131.GB4461@dhcp-200-186.str.redhat.com> References: <20170906094927.22376-1-cohuck@redhat.com> <20170906132936.7cf49b24.cohuck@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170906132936.7cf49b24.cohuck@redhat.com> Subject: Re: [Qemu-devel] [PATCH RFC] accel: default to an actually available accelerator List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: qemu-devel@nongnu.org, lvivier@redhat.com, pbonzini@redhat.com, thuth@redhat.com, mreitz@redhat.com Am 06.09.2017 um 13:29 hat Cornelia Huck geschrieben: > On Wed, 6 Sep 2017 11:49:27 +0200 > Cornelia Huck wrote: > > > configure_accelerator() falls back to tcg if no accelerator has > > been specified. Formerly, we could be sure that tcg is always > > available; however, with --disable-tcg, this is not longer true, > > and you are not able to start qemu without explicitly specifying > > another accelerator on those builds. > > > > Instead, choose an accelerator in the order tcg->kvm->xen->hax. > > > > Signed-off-by: Cornelia Huck > > --- > > > > RFC mainly because this breaks iotest 186 in a different way on a > > tcg-less x86_64 build: Before, it fails with "-machine accel=tcg: No > > accelerator found"; afterwards, there seems to be a difference in > > output due to different autogenerated devices. Not sure how to handle > > that. > > > > cc:ing some hopefully interested folks (-ENOMAINTAINER again). > > > > --- > > accel/accel.c | 22 ++++++++++++++++++++-- > > arch_init.c | 17 +++++++++++++++++ > > include/sysemu/arch_init.h | 2 ++ > > qemu-options.hx | 6 ++++-- > > 4 files changed, 43 insertions(+), 4 deletions(-) > > > > diff --git a/accel/accel.c b/accel/accel.c > > index 8ae40e1e13..26a3f32627 100644 > > --- a/accel/accel.c > > +++ b/accel/accel.c > > @@ -68,6 +68,25 @@ static int accel_init_machine(AccelClass *acc, MachineState *ms) > > return ret; > > } > > > > +static const char *default_accelerator(void) > > +{ > > + if (tcg_available()) { > > + return "tcg"; > > + } > > + if (kvm_available()) { > > + return "kvm"; > > + } > > + if (xen_available()) { > > + return "xen"; > > + } > > + if (hax_available()) { > > + return "hax"; > > + } > > + /* configure makes sure we have at least one accelerator */ > > + g_assert(false); > > + return ""; > > +} > > + > > void configure_accelerator(MachineState *ms) > > { > > const char *accel, *p; > > @@ -79,8 +98,7 @@ void configure_accelerator(MachineState *ms) > > > > accel = qemu_opt_get(qemu_get_machine_opts(), "accel"); > > if (accel == NULL) { > > - /* Use the default "accelerator", tcg */ > > - accel = "tcg"; > > + accel = default_accelerator(); > > It actually may be easier to just switch the default to > "tcg:kvm:xen:hax". Haven't tested that, though. This would have been my first thought and looks a bit simpler, so if it works, I'd go for it. But the real reason why I'm replying: Should we add changing the default to "kvm:tcg" to the list of planned 3.0 changes? I am part of the group that intentionally uses TCG occasionally, but I think the majority of users wants to use KVM (or whatever the fastest option is on their system) whenever it is available. Kevin