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(a)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).
+
+##
+# @query-host-cpu:
+#
+# @migratable: #optional If false, unmigratable features will be
+# returned as well. If true, only migratable features
+# will be returned. Defaults to true.
+#
+# Return information about CPU capabilities in the current host.
+# The returned data may depend on machine and accelerator configuration.
+#
+# Returns: A HostCPUInfo object.
+#
+# Since: 2.7.0
+##
+{ 'command': 'query-host-cpu', 'data': { '*migratable':
'bool' },
+ 'returns': 'HostCPUInfo' }
+
# @AddfdInfo:
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org