[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Gibson
Subject: Re: [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps
Date: Wed, 17 Jan 2018 09:34:13 +1100
User-agent: Mutt/1.9.1 (2017-09-22)

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_!

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]