On Tue, Jun 21, 2016 at 03:48:58PM -0600, Eric Blake wrote:
> On 06/20/2016 02:12 PM, Eduardo Habkost wrote:
> > The command can be used to return host-specific CPU capabilities
> > information.
> >
> > Signed-off-by: Eduardo Habkost <ehabkost@xxxxxxxxxx>
> > ---
> > include/sysemu/arch_init.h | 1 +
> > qapi-schema.json | 36 ++++++++++++++++++++++++++++++++++++
> > qmp-commands.hx | 6 ++++++
> > qmp.c | 13 +++++++++++++
> > stubs/Makefile.objs | 1 +
> > stubs/arch-query-host-cpu-info.c | 8 ++++++++
> > 6 files changed, 65 insertions(+)
> > create mode 100644 stubs/arch-query-host-cpu-info.c
> >
> > diff --git a/include/sysemu/arch_init.h b/include/sysemu/arch_init.h
> > index d690dfa..54215ab 100644
> > --- a/include/sysemu/arch_init.h
> > +++ b/include/sysemu/arch_init.h
> > @@ -35,5 +35,6 @@ int kvm_available(void);
> > int xen_available(void);
> >
> > CpuDefinitionInfoList *arch_query_cpu_definitions(Error **errp);
> > +void arch_query_host_cpu_info(HostCPUInfo *r, bool migratable, Error **errp);
> >
> > #endif
> > diff --git a/qapi-schema.json b/qapi-schema.json
> > index 19e3ef2..d2f4879 100644
> > --- a/qapi-schema.json
> > +++ b/qapi-schema.json
> > @@ -3047,6 +3047,42 @@
> > ##
> > { 'command': 'query-cpu-definitions', 'returns': ['CpuDefinitionInfo'] }
> >
> > +
> > +##
> > +# @HostCPUInfo:
> > +#
> > +# Information on CPU capabilities supported by the current host.
> > +#
> > +# @qom-properties: #optional Values of CPU QOM properties corresponding
> > +# to CPU capabilities supported by the host.
> > +#
> > +# Most properties returned in qom-properties are boolean properties
> > +# indicating if a feature can be enabled in the current host. Other
> > +# non-boolean properties may be returned, the semantics of each property
> > +# depend on the architecture-specific code that handle them.
> > +#
> > +# Since: 2.7.0
>
> Most places in .json files list just 'Since: x.y' rather than 'x.y.z',
> but we aren't consistent enough to insist either way on including or
> excluding a micro release number.
>
> > +##
> > +{ 'struct': 'HostCPUInfo',
> > + 'data': { '*qom-properties': 'any' } }
>
> This is a big hammer that makes the properties non-introspectible - a
> client can tell that properties will be returned, but cannot tell which
> properties to expect nor what format to expect for a given property
> name. I don't know that the interface could be made easily
> introspectible or not (it would probably require some QAPI unions, and a
> LOT more generated code). So it would be nice if we could explore how
> hard it would be to use a type-safe representation instead of 'any',
> before declaring that this is the best we can do. Or, it may be the
> sign of a bigger issue that we have no good way to introspect what qom
> properties to expect, in general (and that solving that would also solve
> this).
What I thought libvirt needed is different from what I though, so
this series will be dropped by now (see the "s390x CPU models:
exposing features" thread). But your comments may still apply
when we look at the alternative "query-cpu-model-expansion"
proposal.
I believe QOM introspection is really the issue here. The CPU
configuration is already based on QOM properties. Manually
duplicating the existing QOM properties into the QAPI
representation would be a waste of time, IMO.
But I agree that the interface could be improved: we should
document very clearly what can be done with the QOM property list
being returned, and return only useful data. For example: we
could only return properties that really makes sense when used
with "-cpu" or "-global" (not every single QOM property), and
document that.
--
Eduardo
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list