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,
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.
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 ;)
--
Andrea Bolognani / Red Hat / Virtualization
