From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bcf6p-0005MQ-VW for qemu-devel@nongnu.org; Wed, 24 Aug 2016 16:49:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bcf6l-0005mf-17 for qemu-devel@nongnu.org; Wed, 24 Aug 2016 16:49:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59988) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bcf6k-0005ma-Oe for qemu-devel@nongnu.org; Wed, 24 Aug 2016 16:49:10 -0400 References: <1472062266-53206-1-git-send-email-dahi@linux.vnet.ibm.com> <1472062266-53206-2-git-send-email-dahi@linux.vnet.ibm.com> From: Eric Blake Message-ID: <57BE0844.3030907@redhat.com> Date: Wed, 24 Aug 2016 15:49:08 -0500 MIME-Version: 1.0 In-Reply-To: <1472062266-53206-2-git-send-email-dahi@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mKWcrRqkvoq4q74Sf1b1V6kERg83PdC5m" Subject: Re: [Qemu-devel] [Patch v3 01/30] qmp: details about CPU definitions in query-cpu-definitions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Hildenbrand , qemu-devel@nongnu.org Cc: ehabkost@redhat.com, borntraeger@de.ibm.com, fiuczy@linux.vnet.ibm.com, cornelia.huck@de.ibm.com, imammedo@redhat.com, jdenemar@redhat.com, mimu@linux.vnet.ibm.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mKWcrRqkvoq4q74Sf1b1V6kERg83PdC5m Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/24/2016 01:10 PM, David Hildenbrand wrote: > It might be of interest for tooling whether a CPU definition can be saf= ely > used when migrating, or if e.g. CPU features might get lost during > migration when migrationg from/to a different QEMU version or host, eve= n if > the same compatibility machine is used. >=20 > Also, we want to know if a CPU definition is static and will never chan= ge. > Beause these definitions can then be used independantly of a compatibil= ity > machine and will always have the same feature set, they can e.g. be use= d > to indicate the "host" model in libvirt later on. >=20 > 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. >=20 > 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 chang= ed > later. >=20 > Signed-off-by: David Hildenbrand > --- > qapi-schema.json | 14 +++++++++++++- > 1 file changed, 13 insertions(+), 1 deletion(-) >=20 > diff --git a/qapi-schema.json b/qapi-schema.json > index 5658723..0d9ae50 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 us= ed for > +# migration in combination with a QEMU compatibility = machine > +# when migrating between different QMU versions and b= etween > +# hosts with different sets of (hardware or software= ) Why two spaces after 'hosts'? > +# capabilities. If not provided, information is not a= vailable > +# and callers should not assume the CPU definition to= be > +# migration-safe. Missing a '(since 2.8)' designation (at least, I'm assuming this is 2.8 material). > +# > +# @static: whether a CPU definition is static and will not change depe= nding on > +# QEMU version, machine type, machine options and accelerator= options. > +# A static model is always migration-safe. Likewise missing a since tag. > +# > # Since: 1.2.0 > ## > { 'struct': 'CpuDefinitionInfo', > - 'data': { 'name': 'str' } } > + 'data': { 'name': 'str', '*migration-safe' : 'bool', 'static' : 'boo= l' } } We aren't consistent on whether to use space before ':' or to put it flush against the key, but it's at least nice to be consistent within a single line. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --mKWcrRqkvoq4q74Sf1b1V6kERg83PdC5m Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXvghEAAoJEKeha0olJ0NqViYIAKxu1YhN0W+d2e0VLqAo8Lv3 bVnnbzVnORBJOQvu5M6gngoTx2CMa8MeBIkrlzrInfr/YBsY24dyO8uXtW1eCeXT RiT0Zrzl8MXbW5NvgPNYL2LvBldFMO7biJXMfpSdwgkYzfDXN43ATd62YPmNH7S0 Lfx/xg6sOldatP7jby+6kcWRFNihtpfCHY6KKgsVYV2pQMO1DDfH38eRo58C9MLx LSUa3LPFtMh7ir2J+++wkilCuofjNXltawJX/rfjA/r+O2RdRKs71QVXwMMn9BqZ IGTDMky/GQr/DkpFmRuHU0G1jCZBjhM0mNAjl9o+5DawYxyIaixHYbhj6SpIkCg= =3Hda -----END PGP SIGNATURE----- --mKWcrRqkvoq4q74Sf1b1V6kERg83PdC5m--