From: Cornelia Huck <cornelia.huck@de.ibm.com>
To: peter.maydell@linaro.org
Cc: borntraeger@de.ibm.com, agraf@suse.de, jfrei@linux.vnet.ibm.com,
qemu-devel@nongnu.org,
David Hildenbrand <dahi@linux.vnet.ibm.com>,
Cornelia Huck <cornelia.huck@de.ibm.com>
Subject: [Qemu-devel] [PULL 10/38] qmp: details about CPU definitions in query-cpu-definitions
Date: Tue, 6 Sep 2016 09:46:42 +0200 [thread overview]
Message-ID: <20160906074710.13495-11-cornelia.huck@de.ibm.com> (raw)
In-Reply-To: <20160906074710.13495-1-cornelia.huck@de.ibm.com>
From: David Hildenbrand <dahi@linux.vnet.ibm.com>
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 <eblake@redhat.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Message-Id: <20160905085244.99980-2-dahi@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
---
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.9.3
next prev parent reply other threads:[~2016-09-06 7:47 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-06 7:46 [Qemu-devel] [PULL 00/38] First set of s390x patches for 2.8 Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 01/38] s390x: add compat machine " Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 02/38] s390x/pci: return directly if create zpci failed Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 03/38] s390x/pci: assert zpci always existing Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 04/38] s390/sclp: cache the sclp device Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 05/38] s390x: wrap flic savevm calls into vmstate Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 06/38] s390x/ioinst: advertise fcs facility Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 07/38] s390x/css: handle cssid 255 correctly Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 08/38] linux-headers: update Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 09/38] s390x/kvm: 2 byte software breakpoint support Cornelia Huck
2016-09-06 7:46 ` Cornelia Huck [this message]
2016-09-06 7:46 ` [Qemu-devel] [PULL 11/38] s390x/cpumodel: "host" and "qemu" as CPU subclasses Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 12/38] s390x/cpumodel: expose CPU class properties Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 13/38] s390x/cpumodel: introduce CPU features Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 14/38] s390x/cpumodel: generate CPU feature lists for CPU models Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 15/38] s390x/cpumodel: generate CPU feature group lists Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 16/38] s390x/cpumodel: introduce CPU feature group definitions Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 17/38] s390x/cpumodel: register defined CPU models as subclasses Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 18/38] s390x/cpumodel: store the CPU model in the CPU instance Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 19/38] s390x/cpumodel: expose features and feature groups as properties Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 20/38] s390x/cpumodel: let the CPU model handle feature checks Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 21/38] s390x/cpumodel: check and apply the CPU model Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 22/38] s390x/sclp: factor out preparation of cpu entries Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 23/38] s390x/sclp: introduce sclp feature blocks Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 24/38] s390x/sclp: indicate sclp features Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 25/38] s390x/sclp: propagate the ibc val (lowest and unblocked ibc) Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 26/38] s390x/sclp: propagate the mha via sclp Cornelia Huck
2016-09-06 7:46 ` [Qemu-devel] [PULL 27/38] s390x/sclp: propagate hmfai Cornelia Huck
2016-09-06 7:47 ` [Qemu-devel] [PULL 28/38] s390x/kvm: allow runtime-instrumentation for "none" machine Cornelia Huck
2016-09-06 7:47 ` [Qemu-devel] [PULL 29/38] s390x/kvm: implement CPU model support Cornelia Huck
2016-09-06 7:47 ` [Qemu-devel] [PULL 30/38] s390x/kvm: disable host model for problematic compat machines Cornelia Huck
2016-09-06 7:47 ` [Qemu-devel] [PULL 31/38] s390x/kvm: let the CPU model control CMM(A) Cornelia Huck
2016-09-06 7:47 ` [Qemu-devel] [PULL 32/38] s390x/kvm: don't enable key wrapping if msa3 is disabled Cornelia Huck
2016-09-06 7:47 ` [Qemu-devel] [PULL 33/38] qmp: add QMP interface "query-cpu-model-expansion" Cornelia Huck
2016-09-06 7:47 ` [Qemu-devel] [PULL 34/38] qmp: add QMP interface "query-cpu-model-comparison" Cornelia Huck
2016-09-08 14:12 ` Eric Blake
2016-09-09 7:39 ` Christian Borntraeger
2016-09-06 7:47 ` [Qemu-devel] [PULL 35/38] qmp: add QMP interface "query-cpu-model-baseline" Cornelia Huck
2016-09-08 14:15 ` Eric Blake
2016-09-06 7:47 ` [Qemu-devel] [PULL 36/38] s390x/cpumodel: implement QMP interface "query-cpu-model-expansion" Cornelia Huck
2016-09-06 7:47 ` [Qemu-devel] [PULL 37/38] s390x/cpumodel: implement QMP interface "query-cpu-model-comparison" Cornelia Huck
2016-09-06 7:47 ` [Qemu-devel] [PULL 38/38] s390x/cpumodel: implement QMP interface "query-cpu-model-baseline" Cornelia Huck
2016-09-06 8:48 ` [Qemu-devel] [PULL 00/38] First set of s390x patches for 2.8 no-reply
2016-09-06 14:32 ` Peter Maydell
2016-09-06 14:49 ` Cornelia Huck
2016-09-06 15:04 ` Cornelia Huck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160906074710.13495-11-cornelia.huck@de.ibm.com \
--to=cornelia.huck@de.ibm.com \
--cc=agraf@suse.de \
--cc=borntraeger@de.ibm.com \
--cc=dahi@linux.vnet.ibm.com \
--cc=jfrei@linux.vnet.ibm.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).