On Wed, Jan 17, 2018 at 10:26:28AM +1100, Alexey Kardashevskiy wrote:
> On 17/01/18 09:34, David Gibson wrote:
> > 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.
>
>
> On a guest started with '-S':
> {"execute": "qom-list", "arguments": {"path": "/machine"}}
>
> returns:
> { 'return': [ {'name': 'graphics', 'type': 'bool'},
> {'name': 'phandle-start', 'type': 'int'},
> {'name': 'dump-guest-core', 'type': 'bool'},
> {'name': 'kernel-irqchip', 'type': 'OnOffSplit'},
> {'name': 'accel', 'type': 'string'},
> {'name': 'append', 'type': 'string'},
> {'name': 'dumpdtb', 'type': 'string'},
> {'name': 'igd-passthru', 'type': 'bool'},
> {'name': 'dt-compatible', 'type': 'string'},
> {'name': 'kernel', 'type': 'string'},
> {'name': 'usb', 'type': 'bool'},
> {'name': 'suppress-vmdesc', 'type': 'bool'},
> {'name': 'dtb', 'type': 'string'},
> {'name': 'firmware', 'type': 'string'},
> {'name': 'mem-merge', 'type': 'bool'},
> {'name': 'initrd', 'type': 'string'},
> {'name': 'enforce-config-section', 'type': 'bool'},
> {'name': 'kvm-shadow-mem', 'type': 'int'},
> {'name': 'cap-dfp', 'type': 'bool'},
> {'name': 'cap-htm', 'type': 'bool'},
> {'name': 'cap-vsx', 'type': 'bool'},
^^^^^^^
Here are the cap properties. Is it just Suraj's new tristate ones
that aren't showing up? If so that's weird... are you sure you built
with those patches included?
> {'name': 'vfio-no-msix-emulation', 'type': 'bool'},
> {'name': 'kvm-type', 'type': 'string'},
> {'name': 'max-cpu-compat', 'type': 'string'},
> { 'name': 'dr-connector[268435480]',
> 'type': 'child<spapr-drc-cpu>'},
> {'name': 'peripheral', 'type': 'child<container>'},
> { 'name': 'dr-connector[268435472]',
> 'type': 'child<spapr-drc-cpu>'},
> {'name': 'modern-hotplug-events', 'type': 'bool'},
> { 'name': 'dr-connector[268435464]',
> 'type': 'child<spapr-drc-cpu>'},
> { 'name': 'dr-connector[268435456]',
> 'type': 'child<spapr-drc-cpu>'},
> {'name': 'peripheral-anon', 'type': 'child<container>'},
> {'name': 'ics', 'type': 'child<icskvm>'},
> {'name': 'vsmt', 'type': 'uint32'},
> {'name': 'type', 'type': 'string'},
> {'name': 'rtc-time', 'type': 'struct tm'},
> {'name': 'unattached', 'type': 'child<container>'},
> {'name': 'rtc', 'type': 'child<spapr-rtc>'},
> {'name': 'resize-hpt', 'type': 'string'}]}
>
>
> but still requires a running qemu, yes.
>
> >
> >> 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
signature.asc
Description: PGP signature
