[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [Patch v4 01/30] qmp: details about CPU definitions in quer
From: |
David Hildenbrand |
Subject: |
[Qemu-devel] [Patch v4 01/30] qmp: details about CPU definitions in query-cpu-definitions |
Date: |
Mon, 5 Sep 2016 10:52:15 +0200 |
It might be of interest for tooling whether a CPU definition can be safely
used when migrating, or if e.g. CPU features might get lost during
migration when migrationg from/to a different QEMU version or host, even if
the same compatibility machine is used.
Also, we want to know if a CPU definition is static and will never change.
Beause these definitions can then be used independantly of a compatibility
machine and will always have the same feature set, they can e.g. be used
to indicate the "host" model in libvirt later on.
Let's add two return values to query-cpu-definitions, stating for each
returned CPU definition, if it is migration-safe and if it is static.
While "migration-safe" is optional, "static" will be set to "false"
automatically by all implementing architectures. If a model really was
static all the time and will be in the future, this can simply be changed
later.
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
---
qapi-schema.json | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index 5658723..1c3533c 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -3038,10 +3038,22 @@
#
# @name: the name of the CPU definition
#
+# @migration-safe: #optional whether a CPU definition can be safely used for
+# migration in combination with a QEMU compatibility machine
+# when migrating between different QMU versions and between
+# hosts with different sets of (hardware or software)
+# capabilities. If not provided, information is not available
+# and callers should not assume the CPU definition to be
+# migration-safe. (since 2.8)
+#
+# @static: whether a CPU definition is static and will not change depending on
+# QEMU version, machine type, machine options and accelerator options.
+# A static model is always migration-safe. (since 2.8)
+#
# Since: 1.2.0
##
{ 'struct': 'CpuDefinitionInfo',
- 'data': { 'name': 'str' } }
+ 'data': { 'name': 'str', '*migration-safe': 'bool', 'static': 'bool' } }
##
# @query-cpu-definitions:
--
2.8.4
- [Qemu-devel] [Patch v4 00/30] s390x CPU models: exposing features, David Hildenbrand, 2016/09/05
- [Qemu-devel] [Patch v4 05/30] s390x/cpumodel: generate CPU feature lists for CPU models, David Hildenbrand, 2016/09/05
- [Qemu-devel] [Patch v4 19/30] linux-headers: update against kvm/next, David Hildenbrand, 2016/09/05
- [Qemu-devel] [Patch v4 09/30] s390x/cpumodel: store the CPU model in the CPU instance, David Hildenbrand, 2016/09/05
- [Qemu-devel] [Patch v4 01/30] qmp: details about CPU definitions in query-cpu-definitions,
David Hildenbrand <=
- [Qemu-devel] [Patch v4 16/30] s390x/sclp: propagate the ibc val(lowest and unblocked ibc), David Hildenbrand, 2016/09/05
- [Qemu-devel] [Patch v4 21/30] s390x/kvm: implement CPU model support, David Hildenbrand, 2016/09/05
- [Qemu-devel] [Patch v4 07/30] s390x/cpumodel: introduce CPU feature group definitions, David Hildenbrand, 2016/09/05
- [Qemu-devel] [Patch v4 20/30] s390x/kvm: allow runtime-instrumentation for "none" machine, David Hildenbrand, 2016/09/05
- [Qemu-devel] [Patch v4 28/30] s390x/cpumodel: implement QMP interface "query-cpu-model-expansion", David Hildenbrand, 2016/09/05
- [Qemu-devel] [Patch v4 27/30] qmp: add QMP interface "query-cpu-model-baseline", David Hildenbrand, 2016/09/05
- [Qemu-devel] [Patch v4 25/30] qmp: add QMP interface "query-cpu-model-expansion", David Hildenbrand, 2016/09/05
- [Qemu-devel] [Patch v4 04/30] s390x/cpumodel: introduce CPU features, David Hildenbrand, 2016/09/05
- [Qemu-devel] [Patch v4 29/30] s390x/cpumodel: implement QMP interface "query-cpu-model-comparison", David Hildenbrand, 2016/09/05
- [Qemu-devel] [Patch v4 14/30] s390x/sclp: introduce sclp feature blocks, David Hildenbrand, 2016/09/05