Re: [Qemu-devel] [PATCH] accel: Improve selection of the default accelerator

[Cornelia Huck <cohuck@redhat.com>]

On Tue, 09 Oct 2018 15:14:59 +0200
Markus Armbruster <armbru@redhat.com> wrote:

> Markus Armbruster <armbru@redhat.com> writes:
> 
> > Peter Maydell <peter.maydell@linaro.org> writes:
> >  
> >> On 5 October 2018 at 15:13, Thomas Huth <thuth@redhat.com> wrote:  
> >>> When compiling with "--disable-tcg", we currently still use "tcg"
> >>> as default accelerator. "kvm" should be used in this case instead.  
> >>
> >> This part is non-controversial and makes good sense.  
> >
> > Agreed.
> >  
> >>> Also, some downstream distros provide QEMU binaries which have "kvm"
> >>> in their names (e.g. "qemu-kvm" on RHEL or "kvm" on Ubuntu) that use
> >>> KVM by default - and some users might want to do something similar
> >>> with upstream binaries, too. Accomodate them by using "kvm:tcg" as
> >>> default when we detect such a binary name.  
> >>
> >> This part is much riskier and less clearly a good plan --
> >> do we really want our behaviour to vary based on the name
> >> of the executable? Distros who want that sort of qemu-kvm
> >> wrapper generally are providing it already (the Ubuntu one
> >> is a 2-line shell script).  
> >
> > I hate it when argv[0] affects behavior[*].  I hate shell wrappers less.
> >
> > If a system provides just one qemu executable, and its default
> > accelerator should be something other than tcg:kvm, then there's a use  
> 
> Correction: "other than tcg".  See configure_accelerator().
> 
> Remind me, why is "tcg" a good default?

I'm not sure why a single accelerator (any of them) would be a good
default. A list (tcg:kvm:<whatever>) sounds much saner, as it would
continue to work even if some accelerators have been disabled (right?)

(And I'd prefer kvm to be first in that list; anything that relies on
tcg being used should specify it explicitly... a normal user will
likely always want the fast variant.)

> 
> > for making it compile-time configurable.  Reading the default from /etc/
> > would also work.  Not sure such a system exists.

Or making it overrideable like that.

> >
> >
> >
> > [*] Go document the behavior with proper precision, and you might come
> > to share the feeling.  
>