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@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