qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Cédric Le Goater" <clg@kaod.org>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Greg Kurz" <groug@kaod.org>,
	qemu-devel@nongnu.org,
	"David Gibson" <david@gibson.dropbear.id.au>,
	"Richard Henderson" <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v2] accel: forbid early use of kvm_enabled() and friends
Date: Fri, 29 Jun 2018 17:09:55 -0300	[thread overview]
Message-ID: <20180629200955.GZ7451@localhost.localdomain> (raw)
In-Reply-To: <f82f360a-045d-099e-c2ae-b5d6507a20a0@redhat.com>

On Fri, Jun 29, 2018 at 01:47:59PM +0200, Paolo Bonzini wrote:
> On 29/06/2018 13:42, Cédric Le Goater wrote:
> >> Yeah, doing anything non-trivial in class_init is just asking for trouble,
> >> as conceivably nothing is initialized at that point. 
> >
> > May be we should consider having a set of binaries for each accelerator,
> > KVM, TCG, etc. That would simplify a lot of the init path of the machines
> > and also of some of the models which are trying to initialize in one mode 
> > or the other.
> 
> That would prevent things like "-machine accel=kvm:tcg", which try KVM
> and fall back to TCG if it is not available.

We could at least make it easier for packagers to choose the
features available on the binaries they build (including
accelerators, machine-types and device models).

As we already have distributions that build a "qemu-kvm" binary
that uses KVM by default, we could make this a supported feature
of the build system instead of requiring downstream
makefile/configure hacks.

-- 
Eduardo

  reply	other threads:[~2018-06-29 20:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-29 10:29 [Qemu-devel] [PATCH v2] accel: forbid early use of kvm_enabled() and friends Greg Kurz
2018-06-29 10:35 ` Paolo Bonzini
2018-06-29 10:39   ` Daniel P. Berrangé
2018-06-29 10:40     ` Paolo Bonzini
2018-06-29 11:07       ` Greg Kurz
2018-06-29 11:08         ` Paolo Bonzini
2018-06-29 11:14           ` Daniel P. Berrangé
2018-06-29 11:42             ` Cédric Le Goater
2018-06-29 11:47               ` Paolo Bonzini
2018-06-29 20:09                 ` Eduardo Habkost [this message]
2018-06-29 15:18             ` Igor Mammedov
2018-06-29 15:19               ` Daniel P. Berrangé
2018-06-29 20:16               ` Eduardo Habkost
2018-06-29 20:34                 ` Eduardo Habkost
2018-07-02 13:44                   ` Greg Kurz
2018-06-29 20:03     ` Eduardo Habkost
2018-06-29 10:48   ` Greg Kurz

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=20180629200955.GZ7451@localhost.localdomain \
    --to=ehabkost@redhat.com \
    --cc=berrange@redhat.com \
    --cc=clg@kaod.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=groug@kaod.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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).