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: 2922 bytes --]

On Thu, Jan 18, 2018 at 04:55:39PM +0100, Andrea Bolognani wrote:
> On Thu, 2018-01-18 at 15:27 +1100, David Gibson wrote:
> > > I looked further and device-list-properties looks like it would
> > > do the trick; however it doesn't seem to work for machines:
> > > 
> > >   {"execute": "device-list-properties",
> > >    "arguments": {"typename": "spapr-2.11-machine"}}
> > >   {"error": {"class": "GenericError",
> > >              "desc": "Parameter 'typename' expects device"}}
> > > 
> > > It works fine for the likes of virtio-scsi-pci and even
> > > power9_v2.0-powerpc64-cpu, though. Any ideas? :)
> > 
> > I'm guessing it's because machines aren't descended from TYPE_DEVICE.
> > 
> > Dammit.  I really can't see a reasonable way of addressing this other
> > than improving qapi in general to have a way of reporting machine
> > class properties.  Adding something ad-hoc for just these properties
> > of this machine seems like madness.
> > 
> > Nor can I think of a place to put these that would be both sensible
> > and more discoverable with existing mechanisms.
> 
> The relationship between QOM/QAPI/QMP is not very clear in my mind,

You and me both :/

> as you might have guessed from my messages, so I don't think I can
> offer much useful input. But if the properties are registered using
> the same mechanism both for devices and machines, then maybe there
> should be a QMP command that can list them regardless of the parent
> type? object-list-properties or something like that.

So, it's a bit complicated.  The underlying mechanism is QOM
properties in all cases.  QOM properties can be constructed either on
a QOM class, or on a QOM instance.  I'm pretty sure
device-list-properties will only list those constructed on the class,
since an instance hasn't been created.

Nearly all properties should be created on the class, not the
instance... but in most cases they're not.  The cap properties *are*
created at the class level, so in principle should be listable in the
same way.

Things derived from TYPE_DEVICE can use that same mechanism directly
but more commonly use a table of properties that's brought over from
the older qdev stuff.  It's translated during class initialization, I
believe, into the QOM backend, but is still used because it's usually
less verbose than constructing QOM properties directly.

> I also noticed that the (AFAIK s390-specific) "loadparm" property
> is detected by libvirt through the query-command-line-options QMP
> command. Not sure what kind of trickery they employ to obtain that
> result, though, and I'm not sure it's exactly an example of best
> practices since it shows up on x86 and aarch64 too ;)

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