All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Markus Armbruster <armbru@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>,
	"Christophe de Dinechin" <dinechin@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Re: Priority of -accel
Date: Tue, 14 Jan 2020 11:44:01 +0100	[thread overview]
Message-ID: <ba331fa5-b45b-72fe-7096-8b4e0cb5f38a@redhat.com> (raw)
In-Reply-To: <87lfqajtwh.fsf@dusky.pond.sub.org>

On 14/01/20 09:59, Markus Armbruster wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
>> On 13/01/20 17:17, Markus Armbruster wrote:
>>> Perfect opportunity to change the default to something more useful.
>>
>> I am not sure acutally if it's that more useful, now that we have
>> sanctioned qemu-kvm as the fast alternative.
> 
> If there is a fast alternative, why ship the slow one?

I find it more consistent that qemu-system-* is doing emulation (and can
usually be ignored) and qemu-kvm is doing virtualization.  It's more
intuitive to launch qemu-system-x86_64 than "qemu-kvm --no-kvm".

What we could do is automatically install a qemu-kvm binary for the
"most suitable" target that has KVM enabled (i.e. for
qemu-system-x86_64, not qemu-system-i386) instead of leaving it to distros.

Paolo

> No matter what we do, somebody is going to be confused.  How to resolve
> such a conundrum?  Utilitarian philosophy teaches us to pursue the
> greatest confusion of the greatest numbers.  I think not using x86
> hardware virtualization by default has been admirably successful there.



  reply	other threads:[~2020-01-14 10:46 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
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 [this message]
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=ba331fa5-b45b-72fe-7096-8b4e0cb5f38a@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dinechin@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@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 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.