Extend query-cpu-definitions schema to allow it to return two new
optional fields: "runnable" and "unavailable-features".
"runnable" will tell if the CPU model can be run in the current
host. "unavailable-features" will contain a list of CPU
properties that are preventing the CPU model from running in the
current host.
Cc: David Hildenbrand <dahi(a)linux.vnet.ibm.com>
Cc: Michael Mueller <mimu(a)linux.vnet.ibm.com>
Cc: Christian Borntraeger <borntraeger(a)de.ibm.com>
Cc: Cornelia Huck <cornelia.huck(a)de.ibm.com>
Cc: Jiri Denemark <jdenemar(a)redhat.com>
Cc: libvir-list(a)redhat.com
Signed-off-by: Eduardo Habkost <ehabkost(a)redhat.com>
---
qapi-schema.json | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index 54634c4..450e6e7 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2948,11 +2948,19 @@
# Virtual CPU definition.
#
# @name: the name of the CPU definition
+# @runnable: true if the CPU model is runnable using the current
+# machine and accelerator. Optional. Since 2.6.
+# @unavailable-features: List of properties that prevent the CPU
+# model from running in the current host,
+# if @runnable is false. Optional.
+# Since 2.6.
Just FYI, on other architectures (e.g. s390x), other conditions (e.g. cpu
generation) also define if a CPU model is runnable, so the pure availability of
features does not mean that a cpu model is runnable.
We could have runnable=false and unavailable-features being an empty list.
#
# Since: 1.2.0
##
{ 'struct': 'CpuDefinitionInfo',
- 'data': { 'name': 'str' } }
+ 'data': { 'name': 'str',
+ '*runnable': 'bool',
+ '*unavailable-features': [ 'str' ] } }
##
# @query-cpu-definitions:
David