Re: [Qemu-devel] [Qemu-ppc] [PATCHv3 0/4] Clean up compatibility mode handling

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2702 bytes --]

On Thu, May 04, 2017 at 09:22:37PM +0200, Greg Kurz wrote:
> On Thu, 04 May 2017 16:32:59 +0200
> Andrea Bolognani <abologna@redhat.com> wrote:
> 
> > On Thu, 2017-04-27 at 17:28 +1000, David Gibson wrote:
> > > 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.  
> > 
> > I started playing with this, mostly with libvirt integration
> > in mind of course, and quickly ran into a behavior that I
> > believe was not intentional and unfortunately managed to slip
> > into 2.9, I assume through the patches which were initially
> > part of this series (mentioned above).
> > 
> > More specifically, when I run a guest with
> > 
> >   -M pseries-2.8 -cpu host
> > 
> > using QEMU 2.8, the CPU in the guest is reported as
> > 
> >   POWER8E (raw), altivec supported
> > 
> > However, when using QEMU 2.9 with the very same command line,
> > including explicitly using the pseries-2.8 machine type, I
> > get
> > 
> >   POWER8 (architected), altivec supported
> > 
> 
> The goal of this series is indeed to switch from raw to architected but I
> agree that it shouldn't affect existing machine types. This probably calls
> for some compat prop.

So, I have mixed feelings about this.

1. Yes, the series was intended to switch from preferring raw to
preferring architected mode.

2. No, it shouldn't have affected older machine types - I didn't think
that through.

But, having made the mistake, I'm not sure it's worth correcting.  I
don't actually expect this to break guests, and fixing it now that
it's already there will be messy, and raises the possibility of new
behavioural change between older and newer subversions of 2.9.


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]