qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Bolognani <abologna@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: Suraj Jitindar Singh <sjitindarsingh@gmail.com>,
	qemu-ppc@nongnu.org, paulus@ozlabs.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps
Date: Tue, 16 Jan 2018 15:46:20 +0100	[thread overview]
Message-ID: <1516113980.3278.1.camel@redhat.com> (raw)
In-Reply-To: <20180116135459.GN30352@umbus.fritz.box>

On Wed, 2018-01-17 at 00:54 +1100, David Gibson wrote:
> > Correct me if I'm wrong, but it seems to me like there's no way
> > to figure out through QMP whether these new machine options can be
> > used for a given QEMU binary.
> 
> Uh, I don't think so.  These are machine options like any other (just
> constructed a bit differently).  So they'll appear in qemu -machine
> pseries,? and I believe that info can also be retrieved with QMP.

Yes, they will indeed show up in the output of -machine pseries,?
but there's AFAICT no way to retrieve them via QMP. And libvirt
can't afford to spawn a QEMU process for each machine type
implemented by each QEMU binary installed on the system just to
figure out what properties they support; in fact, we've been
pushing away from that approach - which was used initially - for
years and we're now at the point where we only fall back to it
for positively ancient QEMU versions. So the information needs
to be available through QMP for libvirt to consume it.

-- 
Andrea Bolognani / Red Hat / Virtualization

  reply	other threads:[~2018-01-16 14:46 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-15  6:32 [Qemu-devel] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps Suraj Jitindar Singh
2018-01-15  6:32 ` [Qemu-devel] [QEMU-PPC] [PATCH V3 1/6] target/ppc/kvm: Add cap_ppc_safe_[cache/bounds_check/indirect_branch] Suraj Jitindar Singh
2018-01-15  6:58   ` [Qemu-devel] [QEMU-PPC] [PATCH V4 " Suraj Jitindar Singh
2018-01-18  5:06     ` David Gibson
2018-01-15  6:32 ` [Qemu-devel] [QEMU-PPC] [PATCH V3 2/6] target/ppc/spapr_caps: Add support for tristate spapr_capabilities Suraj Jitindar Singh
2018-01-18  5:07   ` David Gibson
2018-01-15  6:32 ` [Qemu-devel] [QEMU-PPC] [PATCH V3 3/6] target/ppc/spapr_caps: Add new tristate cap safe_cache Suraj Jitindar Singh
2018-01-18  5:10   ` David Gibson
2018-01-15  6:32 ` [Qemu-devel] [QEMU-PPC] [PATCH V3 4/6] target/ppc/spapr_caps: Add new tristate cap safe_bounds_check Suraj Jitindar Singh
2018-01-18  5:11   ` David Gibson
2018-01-15  6:32 ` [Qemu-devel] [QEMU-PPC] [PATCH V3 5/6] target/ppc/spapr_caps: Add new tristate cap safe_indirect_branch Suraj Jitindar Singh
2018-01-18  5:11   ` David Gibson
2018-01-15  6:32 ` [Qemu-devel] [QEMU-PPC] [PATCH V3 6/6] target/ppc/spapr: Add H-Call H_GET_CPU_CHARACTERISTICS Suraj Jitindar Singh
2018-01-18  5:20   ` David Gibson
2018-01-18  5:44     ` [Qemu-devel] [Qemu-ppc] " Alexey Kardashevskiy
2018-01-18  5:53       ` David Gibson
2018-01-18  8:11         ` Alexey Kardashevskiy
2018-01-18 20:30           ` Eric Blake
2018-01-18 23:35             ` David Gibson
2018-01-18 23:33           ` David Gibson
2018-01-16 13:47 ` [Qemu-devel] [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps Andrea Bolognani
2018-01-16 13:54   ` David Gibson
2018-01-16 14:46     ` Andrea Bolognani [this message]
2018-01-16 22:34       ` David Gibson
2018-01-16 23:26         ` Alexey Kardashevskiy
2018-01-16 23:30           ` David Gibson
2018-01-16 23:46             ` Alexey Kardashevskiy
2018-01-17  1:15               ` David Gibson
2018-01-17  8:54           ` Andrea Bolognani
2018-01-18  4:27             ` David Gibson
2018-01-18 15:55               ` Andrea Bolognani
2018-01-19  2:22                 ` David Gibson
2018-01-19  3:59                   ` Alexey Kardashevskiy

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=1516113980.3278.1.camel@redhat.com \
    --to=abologna@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=paulus@ozlabs.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=sjitindarsingh@gmail.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).