Re: [Qemu-devel] [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 1562 bytes --]

On Tue, Jan 16, 2018 at 03:46:20PM +0100, Andrea Bolognani wrote:
> 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.

Really!?  I thought introspecting object properties was QMP's bread
and butter.

> 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.

Right, I'm not arguing with that.  It's just that I thought that
standard QOM properties on QOM objects (the machine in this case) met
the criteria.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]