qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Christophe de Dinechin <dinechin@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>, "Thomas Huth" <thuth@redhat.com>,
	"Daniel Berrange" <berrange@redhat.com>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org,
	"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
	"Max Reitz" <mreitz@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
Date: Tue, 7 Jan 2020 18:43:30 +0100	[thread overview]
Message-ID: <5FB9F11E-77DC-4FD6-B780-AB508DD42B42@redhat.com> (raw)
In-Reply-To: <360fa010-ba80-b02b-3a35-19c2b48a462d@redhat.com>



> On 7 Jan 2020, at 15:37, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> On 07/01/20 14:55, Christophe de Dinechin wrote:
>> So what about ranking the accelerators, so that all combinaisons
>> -accel=kvm:tcg, -accel=tcg:kvm, -accel kvm -accel tcg, etc would
> 
> (I assume you mean "-machine accel=kvm:tcg" and "-machine accel=tcg:kvm"
> for the first two.  This is the "older" way which has now become sugar
> for "-accel kvm -accel tcg").

Yes.

> 
>> all pickup kvm if available, and tcg as a fallback? Implementation-wise,
>> it would simply mean ranking the accelerators and updating the accelerator
>> only if it’s available and better.
> 
> This is an interesting idea.  I like this better than "-accel best",
> because "-accel best" has the problem that you can't add suboptions to
> it (the suboptions for the various accelerators are disjoint).
> 
> It would break backwards compatibility for "-machine accel=tcg:kvm",
> which so far meant "use TCG if compiled in, otherwise use KVM".  This is
> not something I would have a problem with... except that "tcg:kvm" is
> the default if no -accel option is provided!

What is the rationale for picking tcg over kvm?

My guess is that when this was selected, KVM was the new fancy unstable
thing and this was deemed the safe choice. My other guess is that this was
around 1907 or so :-) My third guess is that you will probably provide me
with a much better rationale ;-)

Without knowing a rationale, my mind goes wild. I’m trying to imagine
who runs qemu directly, without the -accel option. For some reason, I
picture a guy named Joe typing something like "qemu win95.qcow2”,
somewhere in a dark and dusty basement with old neon lamps flashing
in the background and a few rats gnawing at damp CAT5 cables.
Joe is intent on playing Day of the Tentacle one last time before it’s too
late. Joe's only complaint so far has been that the game was a bit slow,
and that’s why he’s nervous and sweats profusely. <insert tense music here>
Will Joe have the time to complete this one last task? <zoom to an old
clock in a corner, ominous tic-toc sound>

Now, it turns out that Joe just updated his system, and suddenly, to his
amazement, Day of the Tentacle is fluid and fast. It’s a miracle!
<insert joyful music here, with a few butterflies flying around for effect>
What is Joe going to do that might be an issue for us? Maybe Joe will
immediately run to Twitter, eyes full of thankful tears, full of a burning
desire to tell the entire world that the qemu folks went totally overboard
with this release and super-optimized it like crazy?

(Consider the above as my way to tell that I’m a bit puzzled as to why
selecting kvm would be a problem. I even intentionally inserted win95,
hoping that this might be one of the scenarios where kvm might be more
trouble than anything, but I don’t know that for sure, having not tested it)



  parent reply	other threads:[~2020-01-07 17:44 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-06 13:09 [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option Philippe Mathieu-Daudé
2020-01-06 13:16 ` Max Reitz
2020-01-07 10:03 ` Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option) Thomas Huth
2020-01-07 10:14   ` Paolo Bonzini
2020-01-07 12:18     ` Thomas Huth
2020-01-07 12:23       ` Paolo Bonzini
2020-01-07 12:54         ` Daniel P. Berrangé
2020-01-07 14:14           ` Thomas Huth
2020-01-07 14:20             ` Priority of -accel Philippe Mathieu-Daudé
2020-01-07 14:27               ` Daniel P. Berrangé
2020-01-07 14:35                 ` Thomas Huth
2020-01-13 14:39                   ` Markus Armbruster
2020-01-13 16:14                     ` Christophe de Dinechin
2020-01-13 16:23                       ` Paolo Bonzini
2020-01-07 14:26             ` Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option) Daniel P. Berrangé
2020-01-08 10:39             ` Alex Bennée
2020-01-08 10:58               ` Thomas Huth
2020-01-08 12:41                 ` Paolo Bonzini
2020-01-08 13:10                   ` Daniel P. Berrangé
2020-01-08 13:24                     ` Paolo Bonzini
2020-01-08 14:00                       ` Priority of -accel Thomas Huth
2020-01-08 11:00               ` Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option) Peter Maydell
2020-01-10 10:43                 ` Peter Maydell
2020-01-07 12:29       ` Kevin Wolf
2020-01-07 12:34       ` Priority of -accel Philippe Mathieu-Daudé
2020-01-07 12:37         ` Philippe Mathieu-Daudé
2020-01-07 13:55     ` Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option) Christophe de Dinechin
2020-01-07 14:37       ` Paolo Bonzini
2020-01-07 14:42         ` Thomas Huth
2020-01-07 17:43         ` Christophe de Dinechin [this message]
2020-01-07 17:53           ` Peter Maydell
2020-01-08  9:47           ` Kevin Wolf
2020-01-13 16:17         ` Priority of -accel Markus Armbruster
2020-01-13 16:25           ` Paolo Bonzini
2020-01-14  8:59             ` Markus Armbruster
2020-01-14 10:44               ` Paolo Bonzini
2020-01-14 17:49             ` Christophe de Dinechin
2020-01-14 17:59               ` Daniel P. Berrangé

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=5FB9F11E-77DC-4FD6-B780-AB508DD42B42@redhat.com \
    --to=dinechin@redhat.com \
    --cc=berrange@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    --cc=wainersm@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;
as well as URLs for NNTP newsgroup(s).