hw/ppc/spapr.c | 6 ++ hw/ppc/spapr_caps.c | 178 ++++++++++++++++++++++++++++++++++++++++ hw/ppc/spapr_hcall.c | 66 +++++++++++++++ include/hw/ppc/spapr.h | 28 ++++++- linux-headers/asm-powerpc/kvm.h | 8 ++ linux-headers/linux/kvm.h | 3 + target/ppc/kvm.c | 58 +++++++++++++ target/ppc/kvm_ppc.h | 18 ++++ 8 files changed, 364 insertions(+), 1 deletion(-)
The following patch series adds 3 new tristate capabilities and their associated handling. A new H-Call is implemented which a guest will use to query the requirement for and availability of workarounds for certain cpu behaviours. Applies on top of David's tree: ppc-for-2.12 The first patch from the previous revision has already been merged: hw/ppc/spapr_caps: Rework spapr_caps to use uint8 internal representation The main changes to V3 are: - Split up the addition of the tristate caps into 5 patches - 1/6 query the caps from the hypervisor and parse the new return format - 2/6 add support for the new caps - 3-5/6 add each of the three new caps - Patch 6/6 Unchanged Suraj Jitindar Singh (6): target/ppc/kvm: Add cap_ppc_safe_[cache/bounds_check/indirect_branch] target/ppc/spapr_caps: Add support for tristate spapr_capabilities target/ppc/spapr_caps: Add new tristate cap safe_cache target/ppc/spapr_caps: Add new tristate cap safe_bounds_check target/ppc/spapr_caps: Add new tristate cap safe_indirect_branch target/ppc/spapr: Add H-Call H_GET_CPU_CHARACTERISTICS hw/ppc/spapr.c | 6 ++ hw/ppc/spapr_caps.c | 178 ++++++++++++++++++++++++++++++++++++++++ hw/ppc/spapr_hcall.c | 66 +++++++++++++++ include/hw/ppc/spapr.h | 28 ++++++- linux-headers/asm-powerpc/kvm.h | 8 ++ linux-headers/linux/kvm.h | 3 + target/ppc/kvm.c | 58 +++++++++++++ target/ppc/kvm_ppc.h | 18 ++++ 8 files changed, 364 insertions(+), 1 deletion(-) -- 2.13.6
On Mon, 2018-01-15 at 17:32 +1100, Suraj Jitindar Singh wrote: > The following patch series adds 3 new tristate capabilities and their > associated handling. > > A new H-Call is implemented which a guest will use to query the > requirement for and availability of workarounds for certain cpu > behaviours. > > Applies on top of David's tree: ppc-for-2.12 > > The first patch from the previous revision has already been merged: > hw/ppc/spapr_caps: Rework spapr_caps to use uint8 internal representation > > The main changes to V3 are: > - Split up the addition of the tristate caps into 5 patches > - 1/6 query the caps from the hypervisor and parse the new return format > - 2/6 add support for the new caps > - 3-5/6 add each of the three new caps > - Patch 6/6 Unchanged 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. If so, that's very unfortunate because it means that libvirt has only two options: 1) just use them if the user requests the corresponding feature, which will lead to older QEMU binaries simply refusing to start; or 2) perform a version number check, which will not be accurate if downstream backports are involved. Would this information be added to the MachineInfo struct, so that query-machines reports it? Or would a new QMP command be more appropriate for the task? Alternatively, if there's any witness we can use instead of an explicit capability, let me know. But I still think we should think about a better long-term solution, especially because this seems to be happening quite frequently lately: see the hpt-resizing and max-cpu-compat machine properties, which are just as opaque from an introspection point of view. Sorry for not bringing this up earlier. -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Jan 16, 2018 at 02:47:13PM +0100, Andrea Bolognani wrote: > On Mon, 2018-01-15 at 17:32 +1100, Suraj Jitindar Singh wrote: > > The following patch series adds 3 new tristate capabilities and their > > associated handling. > > > > A new H-Call is implemented which a guest will use to query the > > requirement for and availability of workarounds for certain cpu > > behaviours. > > > > Applies on top of David's tree: ppc-for-2.12 > > > > The first patch from the previous revision has already been merged: > > hw/ppc/spapr_caps: Rework spapr_caps to use uint8 internal representation > > > > The main changes to V3 are: > > - Split up the addition of the tristate caps into 5 patches > > - 1/6 query the caps from the hypervisor and parse the new return format > > - 2/6 add support for the new caps > > - 3-5/6 add each of the three new caps > > - Patch 6/6 Unchanged > > 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. > If so, that's very unfortunate because it means that libvirt has > only two options: 1) just use them if the user requests the > corresponding feature, which will lead to older QEMU binaries > simply refusing to start; or 2) perform a version number check, > which will not be accurate if downstream backports are involved. > > Would this information be added to the MachineInfo struct, so that > query-machines reports it? Or would a new QMP command be more > appropriate for the task? > > Alternatively, if there's any witness we can use instead of an > explicit capability, let me know. But I still think we should > think about a better long-term solution, especially because this > seems to be happening quite frequently lately: see the hpt-resizing > and max-cpu-compat machine properties, which are just as opaque > from an introspection point of view. > > Sorry for not bringing this up earlier. > -- 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
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. 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. -- Andrea Bolognani / Red Hat / Virtualization
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
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'},
{'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.
>
--
Alexey
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
On 17/01/18 10:30, David Gibson wrote:
> 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?
I am sure I do not have them, my point was that QMP has it all if they are
present in qemu :)
Here is rerun:
{"execute": "qom-list", "arguments": {"path": "/machine"}}
{ '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-ibs', 'type': 'string'},
{'name': 'cap-cfpc', 'type': 'string'},
{'name': 'cap-sbbc', 'type': 'string'},
{'name': 'cap-dfp', 'type': 'bool'},
{'name': 'cap-htm', 'type': 'bool'},
{'name': 'cap-vsx', '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'}]}
and (on unmodified host kernel):
{"execute": "qom-get", "arguments": {"path": "/machine", "property":
"cap-ibs"}}
{'return': 'broken'}
etc.
--
Alexey
On Wed, Jan 17, 2018 at 10:46:45AM +1100, Alexey Kardashevskiy wrote:
> On 17/01/18 10:30, David Gibson wrote:
> > 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?
>
> I am sure I do not have them, my point was that QMP has it all if they are
> present in qemu :)
Oh sorry, I wasn't paying attention. I thought that mail was from
Andrea, not you.
--
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
On Wed, 2018-01-17 at 10:26 +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': 'cap-dfp', 'type': 'bool'},
> {'name': 'cap-htm', 'type': 'bool'},
> {'name': 'cap-vsx', 'type': 'bool'},
> {'name': 'vfio-no-msix-emulation', 'type': 'bool'},
> {'name': 'kvm-type', 'type': 'string'},
> {'name': 'max-cpu-compat', 'type': 'string'},
[...]
> {'name': 'resize-hpt', 'type': 'string'}]}
>
> but still requires a running qemu, yes.
That's not a problem in itself; however, AFAICT the guest in
question also needs to be started with -machine pseries in order
for the above to work, which means it's not usable due to the
scalability issues mentioned earlier in the thread. We run QEMU
with -machine none, a single time, to probe for capabilities.
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? :)
--
Andrea Bolognani / Red Hat / Virtualization
On Wed, Jan 17, 2018 at 09:54:57AM +0100, Andrea Bolognani wrote:
> On Wed, 2018-01-17 at 10:26 +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': 'cap-dfp', 'type': 'bool'},
> > {'name': 'cap-htm', 'type': 'bool'},
> > {'name': 'cap-vsx', 'type': 'bool'},
> > {'name': 'vfio-no-msix-emulation', 'type': 'bool'},
> > {'name': 'kvm-type', 'type': 'string'},
> > {'name': 'max-cpu-compat', 'type': 'string'},
> [...]
> > {'name': 'resize-hpt', 'type': 'string'}]}
> >
> > but still requires a running qemu, yes.
>
> That's not a problem in itself; however, AFAICT the guest in
> question also needs to be started with -machine pseries in order
> for the above to work, which means it's not usable due to the
> scalability issues mentioned earlier in the thread. We run QEMU
> with -machine none, a single time, to probe for capabilities.
>
> 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.
--
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
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
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
On 19/01/18 13:22, David Gibson wrote:
> 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.
There are 2 types of properties really.
typedef struct DeviceClass {
[...]
Property *props;
These are printed by QMP's device-list-properties. Machine is not a device
so we do not see them.
struct ObjectClass
{
[...]
GHashTable *properties;
These are printed by qom-list/get but these QMP commands take path as an
argument and therefore require instances, not classes.
DeviceClass::props migrate to ObjectClass::properties in device_initfn.
So I guess we will either need to:
- merge all the properties to Object/ObjectClass or
- rename&teach device-list-properties to work with objects rather than
devices or
- add qom-list-properties which will only print QOM properties.
The latter is fairly simple, I'll post an rfc patch in few minutes, it will
do like this:
{"execute": "qom-list-properties", "arguments": {"typename":
"pseries-2.11-machine"}}
{ 'return': [ { 'description': 'Set on/off to enable/disable graphics '
'emulation',
'name': 'graphics',
'type': 'bool'},
{ 'description': 'The first phandle ID we may generate '
'dynamically',
'name': 'phandle-start',
'type': 'int'},
{ 'description': 'Include guest memory in a core dump',
'name': 'dump-guest-core',
'type': 'bool'},
{ 'description': 'Configure KVM in-kernel irqchip',
'name': 'kernel-irqchip',
'type': 'OnOffSplit'},
{ 'description': 'Accelerator list',
'name': 'accel',
'type': 'string'},
{ 'description': 'Linux kernel command line',
'name': 'append',
'type': 'string'},
{ 'description': 'Dump current dtb to a file and quit',
'name': 'dumpdtb',
'type': 'string'},
{ 'description': 'Set on/off to enable/disable igd '
'passthrou',
'name': 'igd-passthru',
'type': 'bool'},
{ 'description': 'Overrides the "compatible" property of '
'the dt root node',
'name': 'dt-compatible',
'type': 'string'},
{ 'description': 'Linux kernel image file',
'name': 'kernel',
'type': 'string'},
{ 'description': 'Set on/off to enable/disable usb',
'name': 'usb',
'type': 'bool'},
{ 'description': 'Set on to disable self-describing '
'migration',
'name': 'suppress-vmdesc',
'type': 'bool'},
{ 'description': 'Linux kernel device tree file',
'name': 'dtb',
'type': 'string'},
{ 'description': 'Firmware image',
'name': 'firmware',
'type': 'string'},
{ 'description': 'Enable/disable memory merge support',
'name': 'mem-merge',
'type': 'bool'},
{ 'description': 'Linux initial ramdisk file',
'name': 'initrd',
'type': 'string'},
{ 'description': 'Set on to enforce configuration section '
'migration',
'name': 'enforce-config-section',
'type': 'bool'},
{ 'description': 'KVM shadow MMU size',
'name': 'kvm-shadow-mem',
'type': 'int'},
{ 'description': 'Allow Decimal Floating Point (DFP)',
'name': 'cap-dfp',
'type': 'bool'},
{ 'description': 'Allow Hardware Transactional Memory '
'(HTM)',
'name': 'cap-htm',
'type': 'bool'},
{ 'description': 'Allow Vector Scalar Extensions (VSX)',
'name': 'cap-vsx',
'type': 'bool'},
{'name': 'type', 'type': 'string'},
{ 'description': 'Resizing of the Hash Page Table '
'(enabled, disabled, required)',
'name': 'resize-hpt',
'type': 'string'},
{ 'description': 'Maximum permitted CPU compatibility '
'mode. Valid values are power6, power7, '
'power7+, power8, power9.',
'name': 'max-cpu-compat',
'type': 'string'},
{ 'description': 'Use dedicated hotplug event mechanism
in '
'place of standard EPOW events when '
'possible (required for memory
hot-unplug '
'support)',
'name': 'modern-hotplug-events',
'type': 'bool'},
{ 'description': 'Virtual SMT: KVM behaves as if this
were '
"the host's SMT mode",
'name': 'vsmt',
'type': 'uint32'},
{ 'description': 'Specifies the KVM virtualization mode '
'(HV, PR)',
'name': 'kvm-type',
'type': 'string'},
{'name': 'vfio-no-msix-emulation', 'type': 'bool'}]}
--
Alexey
© 2016 - 2024 Red Hat, Inc.