[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: |
David Hildenbrand |
Subject: |
Re: [Qemu-devel] [Patch v3 01/30] qmp: details about CPU definitions in query-cpu-definitions |
Date: |
Wed, 24 Aug 2016 22:55:26 +0200 |
> 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.
>
All valid and fixed!
Thanks for having a look!
David
- [Qemu-devel] [Patch v3 00/30] s390x CPU models: exposing features, David Hildenbrand, 2016/08/24
- [Qemu-devel] [Patch v3 23/30] s390x/kvm: let the CPU model control CMM(A), David Hildenbrand, 2016/08/24
- [Qemu-devel] [Patch v3 15/30] s390x/sclp: indicate sclp features, David Hildenbrand, 2016/08/24
- [Qemu-devel] [Patch v3 19/30] linux-headers: update against kvm/next, David Hildenbrand, 2016/08/24
- [Qemu-devel] [Patch v3 05/30] s390x/cpumodel: generate CPU feature lists for CPU models, David Hildenbrand, 2016/08/24
- [Qemu-devel] [Patch v3 14/30] s390x/sclp: introduce sclp feature blocks, David Hildenbrand, 2016/08/24
- [Qemu-devel] [Patch v3 10/30] s390x/cpumodel: expose features and feature groups as properties, David Hildenbrand, 2016/08/24
- [Qemu-devel] [Patch v3 07/30] s390x/cpumodel: introduce CPU feature group definitions, David Hildenbrand, 2016/08/24