[libvirt] [Qemu-devel] [PATCH 1/3] qmp: Add query-host-cpu command

Eduardo Habkost ehabkost at redhat.com
Thu Jun 23 16:37:07 UTC 2016


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 at redhat.com>
> > ---
> >  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




More information about the libvir-list mailing list