All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] accel: Improve selection of the default accelerator
Date: Wed, 10 Oct 2018 10:02:07 +0200	[thread overview]
Message-ID: <a69fa7e5-e1a6-bcc7-3de5-169ecd23ffd7@redhat.com> (raw)
In-Reply-To: <fcff0b1e-d3e1-4e8d-48e8-35d0420f5bf5@redhat.com>

On 2018-10-05 23:12, Paolo Bonzini wrote:
> On 05/10/2018 16:22, Peter Maydell wrote:
>> 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.
> 
> Though it probably should be extended to "whpx" and "hvf" (probably
> "xen" too if !CONFIG_KVM).

Sure, I was just unsure whether anybody has ever tried to compile with
--disable-tcg and --disable-kvm and use one of those accelerators
instead? Does it work?

>>> 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 think it makes sense.  At least RHEL has qemu-kvm but no
> qemu-system-x86_64, so it has a non-upstream patch to change the
> accelerator; for other distros there are two benefits:
> 
> 1) now: they could switch to a symlink

Right, I think it's a good idea to avoid wrapper scripts - there is less
chance to get things wrong in this case.

 Thomas

  reply	other threads:[~2018-10-10  8:02 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-05 14:13 [Qemu-devel] [PATCH] accel: Improve selection of the default accelerator Thomas Huth
2018-10-05 14:22 ` Peter Maydell
2018-10-05 21:12   ` Paolo Bonzini
2018-10-10  8:02     ` Thomas Huth [this message]
2018-10-09  9:05   ` Markus Armbruster
2018-10-09 13:14     ` Markus Armbruster
2018-10-09 13:23       ` Thomas Huth
2018-10-09 13:41       ` Daniel P. Berrangé
2018-10-09 13:43       ` Cornelia Huck
2018-10-09 13:58         ` Peter Maydell
2018-10-09 14:23           ` Daniel P. Berrangé
2018-10-09 14:34             ` Peter Maydell
2018-10-09 15:06               ` Cornelia Huck
2018-10-09 15:35             ` Paolo Bonzini
2018-10-05 14:30 ` Cornelia Huck
2018-10-05 14:40   ` Peter Maydell
2018-10-05 21:13   ` Paolo Bonzini
2018-10-05 14:39 ` Philippe Mathieu-Daudé

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=a69fa7e5-e1a6-bcc7-3de5-169ecd23ffd7@redhat.com \
    --to=thuth@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.