On 08/24/2016 01:10 PM, David Hildenbrand wrote: > 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. > > Signed-off-by: David Hildenbrand <d...@linux.vnet.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..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 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)
Why two spaces after 'hosts'?
> +# capabilities. If not provided, information is not
> available
> +# 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 depending
> 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' : 'bool' } }
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.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
