qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Patch v3 01/30] qmp: details about CPU definitions in


From: Eric Blake
Subject: Re: [Qemu-devel] [Patch v3 01/30] qmp: details about CPU definitions in query-cpu-definitions
Date: Wed, 24 Aug 2016 15:49:08 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

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 <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..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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]