[Qemu-devel] [PATCHv4 0/5] Clean up compatibility mode handling

David Gibson posted 5 patches 6 years, 10 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20170526052319.28096-1-david@gibson.dropbear.id.au
Test checkpatch failed
Test docker passed
Test s390x passed
cpus.c                       |   9 ++++
hw/ppc/spapr.c               |   8 +++-
hw/ppc/spapr_cpu_core.c      |  62 +++++++++++++++++++++-----
hw/ppc/spapr_hcall.c         |   8 ++--
include/hw/ppc/spapr.h       |  12 +++--
include/sysemu/cpus.h        |   1 +
include/sysemu/hax.h         |   1 +
include/sysemu/hw_accel.h    |  10 +++++
include/sysemu/kvm.h         |   1 +
kvm-all.c                    |  10 +++++
migration/savevm.c           |   2 +
qapi/string-input-visitor.c  |  11 +++++
qapi/string-output-visitor.c |  14 ++++++
target/i386/hax-all.c        |  10 +++++
target/ppc/compat.c          | 102 +++++++++++++++++++++++++++++++++++++++++++
target/ppc/cpu.h             |   5 ++-
target/ppc/machine.c         |  72 ++++++++++++++++++++++++++++--
target/ppc/translate_init.c  |  86 +++++++++++-------------------------
18 files changed, 340 insertions(+), 84 deletions(-)
[Qemu-devel] [PATCHv4 0/5] Clean up compatibility mode handling
Posted by David Gibson 6 years, 10 months ago
This is a rebased and revised version of my patches revising CPU
compatiblity mode handling on ppc, last posted in November.  Since
then, many of the patches have already been merged (some for 2.9, some
since).  This is what's left.

 * There was conceptual confusion about what a compatibility mode
   means, and how it interacts with the machine type.  This cleans
   that up, clarifying that a compatibility mode (as an externally set
   option) only makes sense on machine types that don't permit the
   guest hypervisor privilege (i.e. 'pseries')

 * It was previously the user's (or management layer's) responsibility
   to determine compatibility of CPUs on either end for migration.
   This uses the compatibility modes to check that properly during an
   incoming migration.

This hasn't been extensively tested yet.  There are quite a few
migration cases to consider, for example:

Basic:

1) Boot guest with -cpu host
        Should go into POWER8 compat mode after CAS
        Previously would have been raw mode

2) Boot guest with -machine pseries,max-cpu-compat=power7 -cpu host
        Should go into POWER7 compat mode

3) Boot guest with -cpu host,compat=power7
        Should act as (2), but print a warning

4) Boot guest via libvirt with power7 compat mode specified in XML
        Should act as (3), (2) once we fix libvirt

5) Hack guest to only advertise power7 compatibility, boot with -cpu host
        Should go into POWER7 compat mode after CAS

6) Hack guest to only advertise real PVRs
        Should remain in POWER8 raw mode after CAS

7) Hack guest to only advertise real PVRs
   Boot with -machine pseries,max-cpu-compat=power8
        Should fail at CAS time

8) Hack guest to only advertise power7 compatibility, boot with -cpu host
   Reboot to normal guest
        Should go to power7 compat mode after CAS of boot 1
        Should revert to raw mode on reboot
        SHould go to power8 compat mode after CAS of boot 2

Migration:

9) Boot guest with qemu-2.6 -machine pseries-2.6 -cpu host
   Migrate to qemu-2.8 -machine pseries-2.6 -cpu host
        Should work, end up running in power8 raw mode

10) Boot guest with qemu-2.7 -machine pseries-2.7 -cpu host
    Migrate to qemu-2.8 -machine pseries-2.7 -cpu host
        Should work, end up running in power8 raw mode

11) Boot guest with qemu-2.7 -machine pseries-2.7 -cpu host,compat=power7
    Migrate to qemu-2.8 -machine pseries-2.7 -cpu host,compat=power7
        Should work, be running in POWER7 compat after, but give warning like
        (3)

12) Boot guest with qemu-2.7 -machine pseries-2.7 -cpu host,compat=power7
    Migrate to qemu-2.8 -machine pseries-2.7,max-cpu-compat=power7 -cpu host
        Should work, be running in POWER7 compat after, no warning

13) Boot to SLOF with qemu-2.6 -machine pseries-2.6 -cpu host
    Migrate to qemu-2.8 -machine pseries-2.6 -cpu host

        ?

14) Boot to SLOF with qemu-2.7 -machine pseries-2.7 -cpu host
    Migrate to qemu-2.8 -machine pseries-2.7 -cpu host
        ?

15) Boot to SLOF with qemu-2.7 -machine pseries-2.7 -cpu host,compat=power7
    Migrate to qemu-2.8 -machine pseries-2.7 -cpu host,compat=power7
        ?

16) Boot to SLOF with qemu-2.7 -machine pseries-2.7 -cpu host,compat=power7
    Migrate to qemu-2.8 -machine pseries-2.7,max-cpu-compat=power7 -cpu host
        ?

17) Boot guest with qemu-2.6 -machine pseries-2.6 -cpu host
    Migrate to qemu-2.7.z -machine pseries-2.6 -cpu host
        Should work

18) Hack guest to only advertise power7 compatibility, boot with -cpu host
    Boot with qemu-2.8, migrate to qemu-2.8
        Should be in power7 compat mode after CAS on source, and still
        in power7 compat mode on destination


Changes since v3:
  * Backwards compatible -cpu handling now removes compat= option from
    options passed on to the cpu, so it doesn't trigger further warnings
  * Add a migration fix make cpu_synchronize_state() safe in post_load
    handlers, which in turn fixes a bug in 5/5.
  * A number of bugfixes and other tweaks suggested by feedback on v2.

Changes since RFCv2:
  * Many patches dropped, since they're already merged
  * Rebased, fixed conflicts
  * Restored support for backwards migration (wasn't as complicated as
    I thought)
  * Updated final patch's description to more accurately reflect the
    logic

Changes since RFCv1:
  * Change CAS logic to prefer compatibility modes over raw mode
  * Simplified by giving up on half-hearted attempts to maintain
    backwards migration
  * Folded migration stream changes into a single patch
  * Removed some preliminary patches which are already merged

David Gibson (4):
  migration: Mark CPU states dirty before incoming migration/loadvm
  pseries: Move CPU compatibility property to machine
  pseries: Reset CPU compatibility mode
  ppc: Rework CPU compatibility testing across migration

Greg Kurz (1):
  qapi: add explicit null to string input and output visitors

 cpus.c                       |   9 ++++
 hw/ppc/spapr.c               |   8 +++-
 hw/ppc/spapr_cpu_core.c      |  62 +++++++++++++++++++++-----
 hw/ppc/spapr_hcall.c         |   8 ++--
 include/hw/ppc/spapr.h       |  12 +++--
 include/sysemu/cpus.h        |   1 +
 include/sysemu/hax.h         |   1 +
 include/sysemu/hw_accel.h    |  10 +++++
 include/sysemu/kvm.h         |   1 +
 kvm-all.c                    |  10 +++++
 migration/savevm.c           |   2 +
 qapi/string-input-visitor.c  |  11 +++++
 qapi/string-output-visitor.c |  14 ++++++
 target/i386/hax-all.c        |  10 +++++
 target/ppc/compat.c          | 102 +++++++++++++++++++++++++++++++++++++++++++
 target/ppc/cpu.h             |   5 ++-
 target/ppc/machine.c         |  72 ++++++++++++++++++++++++++++--
 target/ppc/translate_init.c  |  86 +++++++++++-------------------------
 18 files changed, 340 insertions(+), 84 deletions(-)

-- 
2.9.4


Re: [Qemu-devel] [PATCHv4 0/5] Clean up compatibility mode handling
Posted by Greg Kurz 6 years, 10 months ago
On Fri, 26 May 2017 15:23:14 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

[...]
> 
> 
> Changes since v3:
>   * Backwards compatible -cpu handling now removes compat= option from
>     options passed on to the cpu, so it doesn't trigger further warnings

This seems to also have another interesting effect.

getset_compat_deprecated() could be called either during CPU realization from:

object_property_parse()
{
    Visitor *v = string_input_visitor_new(string);
    object_property_set(obj, v, name, errp);
    ...
}

or during a QOM set operation from:

void object_property_set_qobject(Object *obj, QObject *value,
                                 const char *name, Error **errp)
{
    Visitor *v;

    v = qobject_input_visitor_new(value);
    object_property_set(obj, v, name, errp);
    ...
}

or similarly during a QOM get operation with a QObject output visitor.

The realization path no longer exists with patch 2, so you don't need
to implement a null string input visitor anymore.

This means that patch 1 is no longer needed if I get things right but
you probably want Markus to second that.

>   * Add a migration fix make cpu_synchronize_state() safe in post_load
>     handlers, which in turn fixes a bug in 5/5.
>   * A number of bugfixes and other tweaks suggested by feedback on v2.
> 
> Changes since RFCv2:
>   * Many patches dropped, since they're already merged
>   * Rebased, fixed conflicts
>   * Restored support for backwards migration (wasn't as complicated as
>     I thought)
>   * Updated final patch's description to more accurately reflect the
>     logic
> 
> Changes since RFCv1:
>   * Change CAS logic to prefer compatibility modes over raw mode
>   * Simplified by giving up on half-hearted attempts to maintain
>     backwards migration
>   * Folded migration stream changes into a single patch
>   * Removed some preliminary patches which are already merged
> 
> David Gibson (4):
>   migration: Mark CPU states dirty before incoming migration/loadvm
>   pseries: Move CPU compatibility property to machine
>   pseries: Reset CPU compatibility mode
>   ppc: Rework CPU compatibility testing across migration
> 
> Greg Kurz (1):
>   qapi: add explicit null to string input and output visitors
> 
>  cpus.c                       |   9 ++++
>  hw/ppc/spapr.c               |   8 +++-
>  hw/ppc/spapr_cpu_core.c      |  62 +++++++++++++++++++++-----
>  hw/ppc/spapr_hcall.c         |   8 ++--
>  include/hw/ppc/spapr.h       |  12 +++--
>  include/sysemu/cpus.h        |   1 +
>  include/sysemu/hax.h         |   1 +
>  include/sysemu/hw_accel.h    |  10 +++++
>  include/sysemu/kvm.h         |   1 +
>  kvm-all.c                    |  10 +++++
>  migration/savevm.c           |   2 +
>  qapi/string-input-visitor.c  |  11 +++++
>  qapi/string-output-visitor.c |  14 ++++++
>  target/i386/hax-all.c        |  10 +++++
>  target/ppc/compat.c          | 102 +++++++++++++++++++++++++++++++++++++++++++
>  target/ppc/cpu.h             |   5 ++-
>  target/ppc/machine.c         |  72 ++++++++++++++++++++++++++++--
>  target/ppc/translate_init.c  |  86 +++++++++++-------------------------
>  18 files changed, 340 insertions(+), 84 deletions(-)
> 

Re: [Qemu-devel] [PATCHv4 0/5] Clean up compatibility mode handling
Posted by David Gibson 6 years, 10 months ago
On Tue, May 30, 2017 at 01:14:16AM +0200, Greg Kurz wrote:
> On Fri, 26 May 2017 15:23:14 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> [...]
> > 
> > 
> > Changes since v3:
> >   * Backwards compatible -cpu handling now removes compat= option from
> >     options passed on to the cpu, so it doesn't trigger further warnings
> 
> This seems to also have another interesting effect.
> 
> getset_compat_deprecated() could be called either during CPU realization from:
> 
> object_property_parse()
> {
>     Visitor *v = string_input_visitor_new(string);
>     object_property_set(obj, v, name, errp);
>     ...
> }
> 
> or during a QOM set operation from:
> 
> void object_property_set_qobject(Object *obj, QObject *value,
>                                  const char *name, Error **errp)
> {
>     Visitor *v;
> 
>     v = qobject_input_visitor_new(value);
>     object_property_set(obj, v, name, errp);
>     ...
> }
> 
> or similarly during a QOM get operation with a QObject output visitor.
> 
> The realization path no longer exists with patch 2, so you don't need
> to implement a null string input visitor anymore.

s/patch 2/patch 3/?

Is that true though?  It shouldn't get called through that path in
practice, because we strip the compat property from the cpu object
properties.  But it could get called if either a) the user explicitly
creates a cpu object with -device CPU,compat=whatever or b) if the
user uses the compat= property with a machine type other than pseries.

Of course the user *shouldn't* do either of those things, but
providing a meaningful error if they do is pretty much the whole
purpose of this getter/setter method.

> 
> This means that patch 1 is no longer needed if I get things right but
> you probably want Markus to second that.
> 
> >   * Add a migration fix make cpu_synchronize_state() safe in post_load
> >     handlers, which in turn fixes a bug in 5/5.
> >   * A number of bugfixes and other tweaks suggested by feedback on v2.
> > 
> > Changes since RFCv2:
> >   * Many patches dropped, since they're already merged
> >   * Rebased, fixed conflicts
> >   * Restored support for backwards migration (wasn't as complicated as
> >     I thought)
> >   * Updated final patch's description to more accurately reflect the
> >     logic
> > 
> > Changes since RFCv1:
> >   * Change CAS logic to prefer compatibility modes over raw mode
> >   * Simplified by giving up on half-hearted attempts to maintain
> >     backwards migration
> >   * Folded migration stream changes into a single patch
> >   * Removed some preliminary patches which are already merged
> > 
> > David Gibson (4):
> >   migration: Mark CPU states dirty before incoming migration/loadvm
> >   pseries: Move CPU compatibility property to machine
> >   pseries: Reset CPU compatibility mode
> >   ppc: Rework CPU compatibility testing across migration
> > 
> > Greg Kurz (1):
> >   qapi: add explicit null to string input and output visitors
> > 
> >  cpus.c                       |   9 ++++
> >  hw/ppc/spapr.c               |   8 +++-
> >  hw/ppc/spapr_cpu_core.c      |  62 +++++++++++++++++++++-----
> >  hw/ppc/spapr_hcall.c         |   8 ++--
> >  include/hw/ppc/spapr.h       |  12 +++--
> >  include/sysemu/cpus.h        |   1 +
> >  include/sysemu/hax.h         |   1 +
> >  include/sysemu/hw_accel.h    |  10 +++++
> >  include/sysemu/kvm.h         |   1 +
> >  kvm-all.c                    |  10 +++++
> >  migration/savevm.c           |   2 +
> >  qapi/string-input-visitor.c  |  11 +++++
> >  qapi/string-output-visitor.c |  14 ++++++
> >  target/i386/hax-all.c        |  10 +++++
> >  target/ppc/compat.c          | 102 +++++++++++++++++++++++++++++++++++++++++++
> >  target/ppc/cpu.h             |   5 ++-
> >  target/ppc/machine.c         |  72 ++++++++++++++++++++++++++++--
> >  target/ppc/translate_init.c  |  86 +++++++++++-------------------------
> >  18 files changed, 340 insertions(+), 84 deletions(-)
> > 
> 



-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
Re: [Qemu-devel] [PATCHv4 0/5] Clean up compatibility mode handling
Posted by Greg Kurz 6 years, 10 months ago
On Tue, 30 May 2017 16:18:52 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Tue, May 30, 2017 at 01:14:16AM +0200, Greg Kurz wrote:
> > On Fri, 26 May 2017 15:23:14 +1000
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> > 
> > [...]  
> > > 
> > > 
> > > Changes since v3:
> > >   * Backwards compatible -cpu handling now removes compat= option from
> > >     options passed on to the cpu, so it doesn't trigger further warnings  
> > 
> > This seems to also have another interesting effect.
> > 
> > getset_compat_deprecated() could be called either during CPU realization from:
> > 
> > object_property_parse()
> > {
> >     Visitor *v = string_input_visitor_new(string);
> >     object_property_set(obj, v, name, errp);
> >     ...
> > }
> > 
> > or during a QOM set operation from:
> > 
> > void object_property_set_qobject(Object *obj, QObject *value,
> >                                  const char *name, Error **errp)
> > {
> >     Visitor *v;
> > 
> >     v = qobject_input_visitor_new(value);
> >     object_property_set(obj, v, name, errp);
> >     ...
> > }
> > 
> > or similarly during a QOM get operation with a QObject output visitor.
> > 
> > The realization path no longer exists with patch 2, so you don't need
> > to implement a null string input visitor anymore.  
> 
> s/patch 2/patch 3/?
> 

Yes indeed, sorry :)

> Is that true though?  It shouldn't get called through that path in
> practice, because we strip the compat property from the cpu object
> properties.  But it could get called if either a) the user explicitly
> creates a cpu object with -device CPU,compat=whatever or b) if the

Unless I'm missing something, properties of the CPU objects aren't
exposed by CPU devices:

qemu-system-ppc64 -machine pseries \
                  -device POWER8_v2.0-spapr-cpu-core,help
POWER8_v2.0-spapr-cpu-core.core-id=int
POWER8_v2.0-spapr-cpu-core.node-id=int32
POWER8_v2.0-spapr-cpu-core.nr-threads=int

and creation of CPU objects with -object isn't possible either since
they don't inherit from the TYPE_USER_CREATABLE class.

> user uses the compat= property with a machine type other than pseries.
> 

But yes, it is still possible to go through the object_property_parse()
path with another machine type indeed.

> Of course the user *shouldn't* do either of those things, but
> providing a meaningful error if they do is pretty much the whole
> purpose of this getter/setter method.
> 

All old non-pseries machine types already complain when started with
a POWER7 or newer CPU. Providing the extra error message looks weird:

qemu-system-ppc64 -machine ppce500 \
                  -cpu POWER7,compat=power6
qemu-system-ppc64: CPU 'compat' property is deprecated and has no effect;
 use max-cpu-compat machine property instead
MMU model 983043 not supported by this machine.

but I guess it's better than crashing. :)

> > 
> > This means that patch 1 is no longer needed if I get things right but
> > you probably want Markus to second that.
> >   
> > >   * Add a migration fix make cpu_synchronize_state() safe in post_load
> > >     handlers, which in turn fixes a bug in 5/5.
> > >   * A number of bugfixes and other tweaks suggested by feedback on v2.
> > > 
> > > Changes since RFCv2:
> > >   * Many patches dropped, since they're already merged
> > >   * Rebased, fixed conflicts
> > >   * Restored support for backwards migration (wasn't as complicated as
> > >     I thought)
> > >   * Updated final patch's description to more accurately reflect the
> > >     logic
> > > 
> > > Changes since RFCv1:
> > >   * Change CAS logic to prefer compatibility modes over raw mode
> > >   * Simplified by giving up on half-hearted attempts to maintain
> > >     backwards migration
> > >   * Folded migration stream changes into a single patch
> > >   * Removed some preliminary patches which are already merged
> > > 
> > > David Gibson (4):
> > >   migration: Mark CPU states dirty before incoming migration/loadvm
> > >   pseries: Move CPU compatibility property to machine
> > >   pseries: Reset CPU compatibility mode
> > >   ppc: Rework CPU compatibility testing across migration
> > > 
> > > Greg Kurz (1):
> > >   qapi: add explicit null to string input and output visitors
> > > 
> > >  cpus.c                       |   9 ++++
> > >  hw/ppc/spapr.c               |   8 +++-
> > >  hw/ppc/spapr_cpu_core.c      |  62 +++++++++++++++++++++-----
> > >  hw/ppc/spapr_hcall.c         |   8 ++--
> > >  include/hw/ppc/spapr.h       |  12 +++--
> > >  include/sysemu/cpus.h        |   1 +
> > >  include/sysemu/hax.h         |   1 +
> > >  include/sysemu/hw_accel.h    |  10 +++++
> > >  include/sysemu/kvm.h         |   1 +
> > >  kvm-all.c                    |  10 +++++
> > >  migration/savevm.c           |   2 +
> > >  qapi/string-input-visitor.c  |  11 +++++
> > >  qapi/string-output-visitor.c |  14 ++++++
> > >  target/i386/hax-all.c        |  10 +++++
> > >  target/ppc/compat.c          | 102 +++++++++++++++++++++++++++++++++++++++++++
> > >  target/ppc/cpu.h             |   5 ++-
> > >  target/ppc/machine.c         |  72 ++++++++++++++++++++++++++++--
> > >  target/ppc/translate_init.c  |  86 +++++++++++-------------------------
> > >  18 files changed, 340 insertions(+), 84 deletions(-)
> > >   
> >   
> 
> 
> 

Re: [Qemu-devel] [PATCHv4 0/5] Clean up compatibility mode handling
Posted by David Gibson 6 years, 10 months ago
On Tue, May 30, 2017 at 10:01:36AM +0200, Greg Kurz wrote:
> On Tue, 30 May 2017 16:18:52 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Tue, May 30, 2017 at 01:14:16AM +0200, Greg Kurz wrote:
> > > On Fri, 26 May 2017 15:23:14 +1000
> > > David Gibson <david@gibson.dropbear.id.au> wrote:
> > > 
> > > [...]  
> > > > 
> > > > 
> > > > Changes since v3:
> > > >   * Backwards compatible -cpu handling now removes compat= option from
> > > >     options passed on to the cpu, so it doesn't trigger further warnings  
> > > 
> > > This seems to also have another interesting effect.
> > > 
> > > getset_compat_deprecated() could be called either during CPU realization from:
> > > 
> > > object_property_parse()
> > > {
> > >     Visitor *v = string_input_visitor_new(string);
> > >     object_property_set(obj, v, name, errp);
> > >     ...
> > > }
> > > 
> > > or during a QOM set operation from:
> > > 
> > > void object_property_set_qobject(Object *obj, QObject *value,
> > >                                  const char *name, Error **errp)
> > > {
> > >     Visitor *v;
> > > 
> > >     v = qobject_input_visitor_new(value);
> > >     object_property_set(obj, v, name, errp);
> > >     ...
> > > }
> > > 
> > > or similarly during a QOM get operation with a QObject output visitor.
> > > 
> > > The realization path no longer exists with patch 2, so you don't need
> > > to implement a null string input visitor anymore.  
> > 
> > s/patch 2/patch 3/?
> > 
> 
> Yes indeed, sorry :)
> 
> > Is that true though?  It shouldn't get called through that path in
> > practice, because we strip the compat property from the cpu object
> > properties.  But it could get called if either a) the user explicitly
> > creates a cpu object with -device CPU,compat=whatever or b) if the
> 
> Unless I'm missing something, properties of the CPU objects aren't
> exposed by CPU devices:
> 
> qemu-system-ppc64 -machine pseries \
>                   -device POWER8_v2.0-spapr-cpu-core,help
> POWER8_v2.0-spapr-cpu-core.core-id=int
> POWER8_v2.0-spapr-cpu-core.node-id=int32
> POWER8_v2.0-spapr-cpu-core.nr-threads=int
> 
> and creation of CPU objects with -object isn't possible either since
> they don't inherit from the TYPE_USER_CREATABLE class.

Ah, true, I hadn't considered that.

> > user uses the compat= property with a machine type other than pseries.
> > 
> 
> But yes, it is still possible to go through the object_property_parse()
> path with another machine type indeed.

> > Of course the user *shouldn't* do either of those things, but
> > providing a meaningful error if they do is pretty much the whole
> > purpose of this getter/setter method.
> > 
> 
> All old non-pseries machine types already complain when started with
> a POWER7 or newer CPU. Providing the extra error message looks weird:
> 
> qemu-system-ppc64 -machine ppce500 \
>                   -cpu POWER7,compat=power6
> qemu-system-ppc64: CPU 'compat' property is deprecated and has no effect;
>  use max-cpu-compat machine property instead
> MMU model 983043 not supported by this machine.
> 
> but I guess it's better than crashing. :)

Well, sure POWER7 doesn't make sense for an e500 machine for other
reasons.  But POWER7 or POWER8 _would_ make sense for powernv, where
compat= doesn't.

> 
> > > 
> > > This means that patch 1 is no longer needed if I get things right but
> > > you probably want Markus to second that.
> > >   
> > > >   * Add a migration fix make cpu_synchronize_state() safe in post_load
> > > >     handlers, which in turn fixes a bug in 5/5.
> > > >   * A number of bugfixes and other tweaks suggested by feedback on v2.
> > > > 
> > > > Changes since RFCv2:
> > > >   * Many patches dropped, since they're already merged
> > > >   * Rebased, fixed conflicts
> > > >   * Restored support for backwards migration (wasn't as complicated as
> > > >     I thought)
> > > >   * Updated final patch's description to more accurately reflect the
> > > >     logic
> > > > 
> > > > Changes since RFCv1:
> > > >   * Change CAS logic to prefer compatibility modes over raw mode
> > > >   * Simplified by giving up on half-hearted attempts to maintain
> > > >     backwards migration
> > > >   * Folded migration stream changes into a single patch
> > > >   * Removed some preliminary patches which are already merged
> > > > 
> > > > David Gibson (4):
> > > >   migration: Mark CPU states dirty before incoming migration/loadvm
> > > >   pseries: Move CPU compatibility property to machine
> > > >   pseries: Reset CPU compatibility mode
> > > >   ppc: Rework CPU compatibility testing across migration
> > > > 
> > > > Greg Kurz (1):
> > > >   qapi: add explicit null to string input and output visitors
> > > > 
> > > >  cpus.c                       |   9 ++++
> > > >  hw/ppc/spapr.c               |   8 +++-
> > > >  hw/ppc/spapr_cpu_core.c      |  62 +++++++++++++++++++++-----
> > > >  hw/ppc/spapr_hcall.c         |   8 ++--
> > > >  include/hw/ppc/spapr.h       |  12 +++--
> > > >  include/sysemu/cpus.h        |   1 +
> > > >  include/sysemu/hax.h         |   1 +
> > > >  include/sysemu/hw_accel.h    |  10 +++++
> > > >  include/sysemu/kvm.h         |   1 +
> > > >  kvm-all.c                    |  10 +++++
> > > >  migration/savevm.c           |   2 +
> > > >  qapi/string-input-visitor.c  |  11 +++++
> > > >  qapi/string-output-visitor.c |  14 ++++++
> > > >  target/i386/hax-all.c        |  10 +++++
> > > >  target/ppc/compat.c          | 102 +++++++++++++++++++++++++++++++++++++++++++
> > > >  target/ppc/cpu.h             |   5 ++-
> > > >  target/ppc/machine.c         |  72 ++++++++++++++++++++++++++++--
> > > >  target/ppc/translate_init.c  |  86 +++++++++++-------------------------
> > > >  18 files changed, 340 insertions(+), 84 deletions(-)
> > > >   
> > >   
> > 
> > 
> > 
> 



-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
Re: [Qemu-devel] [PATCHv4 0/5] Clean up compatibility mode handling
Posted by Greg Kurz 6 years, 10 months ago
On Wed, 31 May 2017 12:57:48 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> [...]
> > All old non-pseries machine types already complain when started with
> > a POWER7 or newer CPU. Providing the extra error message looks weird:
> > 
> > qemu-system-ppc64 -machine ppce500 \
> >                   -cpu POWER7,compat=power6
> > qemu-system-ppc64: CPU 'compat' property is deprecated and has no effect;
> >  use max-cpu-compat machine property instead
> > MMU model 983043 not supported by this machine.
> > 
> > but I guess it's better than crashing. :)  
> 
> Well, sure POWER7 doesn't make sense for an e500 machine for other
> reasons.  But POWER7 or POWER8 _would_ make sense for powernv, where
> compat= doesn't.
> 

The powernv machine type doesn't even support CPU features at all:

    chip_typename = g_strdup_printf(TYPE_PNV_CHIP "-%s", machine->cpu_model);
    if (!object_class_by_name(chip_typename)) {
        error_report("invalid CPU model '%s' for %s machine",
                     machine->cpu_model, MACHINE_GET_CLASS(machine)->name);
        exit(1);
    }

> >   
> > > > 
> > > > This means that patch 1 is no longer needed if I get things right but
> > > > you probably want Markus to second that.
> > > >     
> > > > >   * Add a migration fix make cpu_synchronize_state() safe in post_load
> > > > >     handlers, which in turn fixes a bug in 5/5.
> > > > >   * A number of bugfixes and other tweaks suggested by feedback on v2.
> > > > > 
> > > > > Changes since RFCv2:
> > > > >   * Many patches dropped, since they're already merged
> > > > >   * Rebased, fixed conflicts
> > > > >   * Restored support for backwards migration (wasn't as complicated as
> > > > >     I thought)
> > > > >   * Updated final patch's description to more accurately reflect the
> > > > >     logic
> > > > > 
> > > > > Changes since RFCv1:
> > > > >   * Change CAS logic to prefer compatibility modes over raw mode
> > > > >   * Simplified by giving up on half-hearted attempts to maintain
> > > > >     backwards migration
> > > > >   * Folded migration stream changes into a single patch
> > > > >   * Removed some preliminary patches which are already merged
> > > > > 
> > > > > David Gibson (4):
> > > > >   migration: Mark CPU states dirty before incoming migration/loadvm
> > > > >   pseries: Move CPU compatibility property to machine
> > > > >   pseries: Reset CPU compatibility mode
> > > > >   ppc: Rework CPU compatibility testing across migration
> > > > > 
> > > > > Greg Kurz (1):
> > > > >   qapi: add explicit null to string input and output visitors
> > > > > 
> > > > >  cpus.c                       |   9 ++++
> > > > >  hw/ppc/spapr.c               |   8 +++-
> > > > >  hw/ppc/spapr_cpu_core.c      |  62 +++++++++++++++++++++-----
> > > > >  hw/ppc/spapr_hcall.c         |   8 ++--
> > > > >  include/hw/ppc/spapr.h       |  12 +++--
> > > > >  include/sysemu/cpus.h        |   1 +
> > > > >  include/sysemu/hax.h         |   1 +
> > > > >  include/sysemu/hw_accel.h    |  10 +++++
> > > > >  include/sysemu/kvm.h         |   1 +
> > > > >  kvm-all.c                    |  10 +++++
> > > > >  migration/savevm.c           |   2 +
> > > > >  qapi/string-input-visitor.c  |  11 +++++
> > > > >  qapi/string-output-visitor.c |  14 ++++++
> > > > >  target/i386/hax-all.c        |  10 +++++
> > > > >  target/ppc/compat.c          | 102 +++++++++++++++++++++++++++++++++++++++++++
> > > > >  target/ppc/cpu.h             |   5 ++-
> > > > >  target/ppc/machine.c         |  72 ++++++++++++++++++++++++++++--
> > > > >  target/ppc/translate_init.c  |  86 +++++++++++-------------------------
> > > > >  18 files changed, 340 insertions(+), 84 deletions(-)
> > > > >     
> > > >     
> > > 
> > > 
> > >   
> >   
> 
> 
> 

Re: [Qemu-devel] [PATCHv4 0/5] Clean up compatibility mode handling
Posted by David Gibson 6 years, 10 months ago
On Wed, May 31, 2017 at 10:58:57AM +0200, Greg Kurz wrote:
> On Wed, 31 May 2017 12:57:48 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
> > [...]
> > > All old non-pseries machine types already complain when started with
> > > a POWER7 or newer CPU. Providing the extra error message looks weird:
> > > 
> > > qemu-system-ppc64 -machine ppce500 \
> > >                   -cpu POWER7,compat=power6
> > > qemu-system-ppc64: CPU 'compat' property is deprecated and has no effect;
> > >  use max-cpu-compat machine property instead
> > > MMU model 983043 not supported by this machine.
> > > 
> > > but I guess it's better than crashing. :)  
> > 
> > Well, sure POWER7 doesn't make sense for an e500 machine for other
> > reasons.  But POWER7 or POWER8 _would_ make sense for powernv, where
> > compat= doesn't.
> > 
> 
> The powernv machine type doesn't even support CPU features at all:
> 
>     chip_typename = g_strdup_printf(TYPE_PNV_CHIP "-%s", machine->cpu_model);
>     if (!object_class_by_name(chip_typename)) {
>         error_report("invalid CPU model '%s' for %s machine",
>                      machine->cpu_model, MACHINE_GET_CLASS(machine)->name);
>         exit(1);
>     }

Ah, well, that's another bug, but not one that's in scope for this
series.



-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
Re: [Qemu-devel] [PATCHv4 0/5] Clean up compatibility mode handling
Posted by Cédric Le Goater 6 years, 10 months ago
On 06/01/2017 08:52 AM, David Gibson wrote:
> On Wed, May 31, 2017 at 10:58:57AM +0200, Greg Kurz wrote:
>> On Wed, 31 May 2017 12:57:48 +1000
>> David Gibson <david@gibson.dropbear.id.au> wrote:
>>> [...]
>>>> All old non-pseries machine types already complain when started with
>>>> a POWER7 or newer CPU. Providing the extra error message looks weird:
>>>>
>>>> qemu-system-ppc64 -machine ppce500 \
>>>>                   -cpu POWER7,compat=power6
>>>> qemu-system-ppc64: CPU 'compat' property is deprecated and has no effect;
>>>>  use max-cpu-compat machine property instead
>>>> MMU model 983043 not supported by this machine.
>>>>
>>>> but I guess it's better than crashing. :)  
>>>
>>> Well, sure POWER7 doesn't make sense for an e500 machine for other
>>> reasons.  But POWER7 or POWER8 _would_ make sense for powernv, where
>>> compat= doesn't.
>>>
>>
>> The powernv machine type doesn't even support CPU features at all:
>>
>>     chip_typename = g_strdup_printf(TYPE_PNV_CHIP "-%s", machine->cpu_model);
>>     if (!object_class_by_name(chip_typename)) {
>>         error_report("invalid CPU model '%s' for %s machine",
>>                      machine->cpu_model, MACHINE_GET_CLASS(machine)->name);
>>         exit(1);
>>     }
> 
> Ah, well, that's another bug, but not one that's in scope for this
> series.

PowerNV is still work in progress. I would not worry about it too much.

C. 


Re: [Qemu-devel] [PATCHv4 0/5] Clean up compatibility mode handling
Posted by Greg Kurz 6 years, 10 months ago
On Thu, 1 Jun 2017 13:59:14 +0200
Cédric Le Goater <clg@kaod.org> wrote:

> On 06/01/2017 08:52 AM, David Gibson wrote:
> > On Wed, May 31, 2017 at 10:58:57AM +0200, Greg Kurz wrote:  
> >> On Wed, 31 May 2017 12:57:48 +1000
> >> David Gibson <david@gibson.dropbear.id.au> wrote:  
> >>> [...]  
> >>>> All old non-pseries machine types already complain when started with
> >>>> a POWER7 or newer CPU. Providing the extra error message looks weird:
> >>>>
> >>>> qemu-system-ppc64 -machine ppce500 \
> >>>>                   -cpu POWER7,compat=power6
> >>>> qemu-system-ppc64: CPU 'compat' property is deprecated and has no effect;
> >>>>  use max-cpu-compat machine property instead
> >>>> MMU model 983043 not supported by this machine.
> >>>>
> >>>> but I guess it's better than crashing. :)    
> >>>
> >>> Well, sure POWER7 doesn't make sense for an e500 machine for other
> >>> reasons.  But POWER7 or POWER8 _would_ make sense for powernv, where
> >>> compat= doesn't.
> >>>  
> >>
> >> The powernv machine type doesn't even support CPU features at all:
> >>
> >>     chip_typename = g_strdup_printf(TYPE_PNV_CHIP "-%s", machine->cpu_model);
> >>     if (!object_class_by_name(chip_typename)) {
> >>         error_report("invalid CPU model '%s' for %s machine",
> >>                      machine->cpu_model, MACHINE_GET_CLASS(machine)->name);
> >>         exit(1);
> >>     }  
> > 
> > Ah, well, that's another bug, but not one that's in scope for this
> > series.  
> 
> PowerNV is still work in progress. I would not worry about it too much.
> 

Of course and this isn't the purpose of the discussion actually. We were
talking about CPU features being relevant or not depending on the machine
type.

But I'm not even sure that CPU features are useful at all for ppc, not to
say very confusing (otherwise this series wouldn't be needed for example).

Speaking of PowerNV, just as an example, I guess the fix would be to
forbid machine->cpu_model if it contains features. And probably the same
for all other machine types, except pseries for backward compatibility
reasons.

> C. 
> 

Re: [Qemu-devel] [PATCHv4 0/5] Clean up compatibility mode handling
Posted by David Gibson 6 years, 9 months ago
On Thu, Jun 01, 2017 at 03:09:15PM +0200, Greg Kurz wrote:
> On Thu, 1 Jun 2017 13:59:14 +0200
> Cédric Le Goater <clg@kaod.org> wrote:
> 
> > On 06/01/2017 08:52 AM, David Gibson wrote:
> > > On Wed, May 31, 2017 at 10:58:57AM +0200, Greg Kurz wrote:  
> > >> On Wed, 31 May 2017 12:57:48 +1000
> > >> David Gibson <david@gibson.dropbear.id.au> wrote:  
> > >>> [...]  
> > >>>> All old non-pseries machine types already complain when started with
> > >>>> a POWER7 or newer CPU. Providing the extra error message looks weird:
> > >>>>
> > >>>> qemu-system-ppc64 -machine ppce500 \
> > >>>>                   -cpu POWER7,compat=power6
> > >>>> qemu-system-ppc64: CPU 'compat' property is deprecated and has no effect;
> > >>>>  use max-cpu-compat machine property instead
> > >>>> MMU model 983043 not supported by this machine.
> > >>>>
> > >>>> but I guess it's better than crashing. :)    
> > >>>
> > >>> Well, sure POWER7 doesn't make sense for an e500 machine for other
> > >>> reasons.  But POWER7 or POWER8 _would_ make sense for powernv, where
> > >>> compat= doesn't.
> > >>>  
> > >>
> > >> The powernv machine type doesn't even support CPU features at all:
> > >>
> > >>     chip_typename = g_strdup_printf(TYPE_PNV_CHIP "-%s", machine->cpu_model);
> > >>     if (!object_class_by_name(chip_typename)) {
> > >>         error_report("invalid CPU model '%s' for %s machine",
> > >>                      machine->cpu_model, MACHINE_GET_CLASS(machine)->name);
> > >>         exit(1);
> > >>     }  
> > > 
> > > Ah, well, that's another bug, but not one that's in scope for this
> > > series.  
> > 
> > PowerNV is still work in progress. I would not worry about it too much.
> > 
> 
> Of course and this isn't the purpose of the discussion actually. We were
> talking about CPU features being relevant or not depending on the machine
> type.
> 
> But I'm not even sure that CPU features are useful at all for ppc, not to
> say very confusing (otherwise this series wouldn't be needed for example).
> 
> Speaking of PowerNV, just as an example, I guess the fix would be to
> forbid machine->cpu_model if it contains features. And probably the same
> for all other machine types, except pseries for backward compatibility
> reasons.

I don't think that's correct in principle.  I can imagine CPU
properties it might make sense to really set on the cpu, regardless of
machine type.  A quick look says we don't have any such at the moment,
but I don't think it's something we should prevent as a matter of policy.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
Re: [Qemu-devel] [PATCHv4 0/5] Clean up compatibility mode handling
Posted by Greg Kurz 6 years, 9 months ago
On Fri, 2 Jun 2017 12:00:07 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Thu, Jun 01, 2017 at 03:09:15PM +0200, Greg Kurz wrote:
> > On Thu, 1 Jun 2017 13:59:14 +0200
> > Cédric Le Goater <clg@kaod.org> wrote:
> >   
> > > On 06/01/2017 08:52 AM, David Gibson wrote:  
> > > > On Wed, May 31, 2017 at 10:58:57AM +0200, Greg Kurz wrote:    
> > > >> On Wed, 31 May 2017 12:57:48 +1000
> > > >> David Gibson <david@gibson.dropbear.id.au> wrote:    
> > > >>> [...]    
> > > >>>> All old non-pseries machine types already complain when started with
> > > >>>> a POWER7 or newer CPU. Providing the extra error message looks weird:
> > > >>>>
> > > >>>> qemu-system-ppc64 -machine ppce500 \
> > > >>>>                   -cpu POWER7,compat=power6
> > > >>>> qemu-system-ppc64: CPU 'compat' property is deprecated and has no effect;
> > > >>>>  use max-cpu-compat machine property instead
> > > >>>> MMU model 983043 not supported by this machine.
> > > >>>>
> > > >>>> but I guess it's better than crashing. :)      
> > > >>>
> > > >>> Well, sure POWER7 doesn't make sense for an e500 machine for other
> > > >>> reasons.  But POWER7 or POWER8 _would_ make sense for powernv, where
> > > >>> compat= doesn't.
> > > >>>    
> > > >>
> > > >> The powernv machine type doesn't even support CPU features at all:
> > > >>
> > > >>     chip_typename = g_strdup_printf(TYPE_PNV_CHIP "-%s", machine->cpu_model);
> > > >>     if (!object_class_by_name(chip_typename)) {
> > > >>         error_report("invalid CPU model '%s' for %s machine",
> > > >>                      machine->cpu_model, MACHINE_GET_CLASS(machine)->name);
> > > >>         exit(1);
> > > >>     }    
> > > > 
> > > > Ah, well, that's another bug, but not one that's in scope for this
> > > > series.    
> > > 
> > > PowerNV is still work in progress. I would not worry about it too much.
> > >   
> > 
> > Of course and this isn't the purpose of the discussion actually. We were
> > talking about CPU features being relevant or not depending on the machine
> > type.
> > 
> > But I'm not even sure that CPU features are useful at all for ppc, not to
> > say very confusing (otherwise this series wouldn't be needed for example).
> > 
> > Speaking of PowerNV, just as an example, I guess the fix would be to
> > forbid machine->cpu_model if it contains features. And probably the same
> > for all other machine types, except pseries for backward compatibility
> > reasons.  
> 
> I don't think that's correct in principle.  I can imagine CPU
> properties it might make sense to really set on the cpu, regardless of
> machine type.  A quick look says we don't have any such at the moment,
> but I don't think it's something we should prevent as a matter of policy.
> 

Fair enough. Then maybe all machine should parse CPU features and check which
one are valid before instantiating the CPUs ?
Re: [Qemu-devel] [PATCHv4 0/5] Clean up compatibility mode handling
Posted by David Gibson 6 years, 9 months ago
On Fri, Jun 02, 2017 at 10:15:25AM +0200, Greg Kurz wrote:
> On Fri, 2 Jun 2017 12:00:07 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Thu, Jun 01, 2017 at 03:09:15PM +0200, Greg Kurz wrote:
> > > On Thu, 1 Jun 2017 13:59:14 +0200
> > > Cédric Le Goater <clg@kaod.org> wrote:
> > >   
> > > > On 06/01/2017 08:52 AM, David Gibson wrote:  
> > > > > On Wed, May 31, 2017 at 10:58:57AM +0200, Greg Kurz wrote:    
> > > > >> On Wed, 31 May 2017 12:57:48 +1000
> > > > >> David Gibson <david@gibson.dropbear.id.au> wrote:    
> > > > >>> [...]    
> > > > >>>> All old non-pseries machine types already complain when started with
> > > > >>>> a POWER7 or newer CPU. Providing the extra error message looks weird:
> > > > >>>>
> > > > >>>> qemu-system-ppc64 -machine ppce500 \
> > > > >>>>                   -cpu POWER7,compat=power6
> > > > >>>> qemu-system-ppc64: CPU 'compat' property is deprecated and has no effect;
> > > > >>>>  use max-cpu-compat machine property instead
> > > > >>>> MMU model 983043 not supported by this machine.
> > > > >>>>
> > > > >>>> but I guess it's better than crashing. :)      
> > > > >>>
> > > > >>> Well, sure POWER7 doesn't make sense for an e500 machine for other
> > > > >>> reasons.  But POWER7 or POWER8 _would_ make sense for powernv, where
> > > > >>> compat= doesn't.
> > > > >>>    
> > > > >>
> > > > >> The powernv machine type doesn't even support CPU features at all:
> > > > >>
> > > > >>     chip_typename = g_strdup_printf(TYPE_PNV_CHIP "-%s", machine->cpu_model);
> > > > >>     if (!object_class_by_name(chip_typename)) {
> > > > >>         error_report("invalid CPU model '%s' for %s machine",
> > > > >>                      machine->cpu_model, MACHINE_GET_CLASS(machine)->name);
> > > > >>         exit(1);
> > > > >>     }    
> > > > > 
> > > > > Ah, well, that's another bug, but not one that's in scope for this
> > > > > series.    
> > > > 
> > > > PowerNV is still work in progress. I would not worry about it too much.
> > > >   
> > > 
> > > Of course and this isn't the purpose of the discussion actually. We were
> > > talking about CPU features being relevant or not depending on the machine
> > > type.
> > > 
> > > But I'm not even sure that CPU features are useful at all for ppc, not to
> > > say very confusing (otherwise this series wouldn't be needed for example).
> > > 
> > > Speaking of PowerNV, just as an example, I guess the fix would be to
> > > forbid machine->cpu_model if it contains features. And probably the same
> > > for all other machine types, except pseries for backward compatibility
> > > reasons.  
> > 
> > I don't think that's correct in principle.  I can imagine CPU
> > properties it might make sense to really set on the cpu, regardless of
> > machine type.  A quick look says we don't have any such at the moment,
> > but I don't think it's something we should prevent as a matter of policy.
> 
> Fair enough. Then maybe all machine should parse CPU features and check which
> one are valid before instantiating the CPUs ?

Well, CPu properties *should* be valid for all machine types.  The
fact that compat= wasn't was a mistake.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
Re: [Qemu-devel] [PATCHv4 0/5] Clean up compatibility mode handling
Posted by David Gibson 6 years, 9 months ago
On Thu, Jun 01, 2017 at 01:59:14PM +0200, Cédric Le Goater wrote:
> On 06/01/2017 08:52 AM, David Gibson wrote:
> > On Wed, May 31, 2017 at 10:58:57AM +0200, Greg Kurz wrote:
> >> On Wed, 31 May 2017 12:57:48 +1000
> >> David Gibson <david@gibson.dropbear.id.au> wrote:
> >>> [...]
> >>>> All old non-pseries machine types already complain when started with
> >>>> a POWER7 or newer CPU. Providing the extra error message looks weird:
> >>>>
> >>>> qemu-system-ppc64 -machine ppce500 \
> >>>>                   -cpu POWER7,compat=power6
> >>>> qemu-system-ppc64: CPU 'compat' property is deprecated and has no effect;
> >>>>  use max-cpu-compat machine property instead
> >>>> MMU model 983043 not supported by this machine.
> >>>>
> >>>> but I guess it's better than crashing. :)  
> >>>
> >>> Well, sure POWER7 doesn't make sense for an e500 machine for other
> >>> reasons.  But POWER7 or POWER8 _would_ make sense for powernv, where
> >>> compat= doesn't.
> >>>
> >>
> >> The powernv machine type doesn't even support CPU features at all:
> >>
> >>     chip_typename = g_strdup_printf(TYPE_PNV_CHIP "-%s", machine->cpu_model);
> >>     if (!object_class_by_name(chip_typename)) {
> >>         error_report("invalid CPU model '%s' for %s machine",
> >>                      machine->cpu_model, MACHINE_GET_CLASS(machine)->name);
> >>         exit(1);
> >>     }
> > 
> > Ah, well, that's another bug, but not one that's in scope for this
> > series.
> 
> PowerNV is still work in progress. I would not worry about it too much.

I wasn't intending to :).

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
Re: [Qemu-devel] [PATCHv4 0/5] Clean up compatibility mode handling
Posted by no-reply@patchew.org 6 years, 10 months ago
Hi,

This series seems to have some coding style problems. See output below for
more information:

Message-id: 20170526052319.28096-1-david@gibson.dropbear.id.au
Type: series
Subject: [Qemu-devel] [PATCHv4 0/5] Clean up compatibility mode handling

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
    echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
    if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
        failed=1
        echo
    fi
    n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
ab1e546 ppc: Rework CPU compatibility testing across migration
9506d9a pseries: Reset CPU compatibility mode
c974c40 pseries: Move CPU compatibility property to machine
ae5875d migration: Mark CPU states dirty before incoming migration/loadvm
e3081d0 qapi: add explicit null to string input and output visitors

=== OUTPUT BEGIN ===
Checking PATCH 1/5: qapi: add explicit null to string input and output visitors...
Checking PATCH 2/5: migration: Mark CPU states dirty before incoming migration/loadvm...
WARNING: line over 80 characters
#119: FILE: kvm-all.c:1899:
+static void do_kvm_cpu_synchronize_pre_loadvm(CPUState *cpu, run_on_cpu_data arg)

WARNING: line over 80 characters
#153: FILE: target/i386/hax-all.c:638:
+static void do_hax_cpu_synchronize_pre_loadvm(CPUState *cpu, run_on_cpu_data arg)

total: 0 errors, 2 warnings, 90 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Checking PATCH 3/5: pseries: Move CPU compatibility property to machine...
Checking PATCH 4/5: pseries: Reset CPU compatibility mode...
Checking PATCH 5/5: ppc: Rework CPU compatibility testing across migration...
ERROR: braces {} are necessary for all arms of this statement
#97: FILE: target/ppc/machine.c:239:
+    if (cpu->compat_pvr) {
[...]
+    } else
[...]

total: 1 errors, 0 warnings, 103 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-devel@freelists.org