Re: [Qemu-devel] [Qemu-ppc] [PULL 11/18] pseries: Split CAS PVR negotiation out into a separate function

From: Greg Kurz <groug@kaod.org>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org,
	sursingh@redhat.com, mdroth@linux.vnet.ibm.com,
	qemu-ppc@nongnu.org, sbobroff@redhat.com
Subject: Re: [Qemu-devel] [Qemu-ppc] [PULL 11/18] pseries: Split CAS PVR negotiation out into a separate function
Date: Wed, 31 May 2017 11:01:15 +0200	[thread overview]
Message-ID: <20170531110115.7d44d86e@bahia.ttt.fr.ibm.com> (raw)
In-Reply-To: <20170531063321.GL12163@umbus.fritz.box>

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

On Wed, 31 May 2017 16:33:21 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Mon, May 29, 2017 at 11:14:08PM +0200, Greg Kurz wrote:
> > On Thu, 25 May 2017 13:51:25 +1000
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> >   
> > > Guests of the qemu machine type go through a feature negotiation process
> > > known as "client architecture support" (CAS) during early boot.  This does
> > > a number of things, one of which is finding a CPU compatibility mode which
> > > can be supported by both guest and host.
> > > 
> > > In fact the CPU negotiation is probably the single most complex part of the
> > > CAS process, so this splits it out into a helper function.  We've recently
> > > made some mistakes in maintaining backward compatibility for old machine
> > > types here.  Splitting this out will also make it easier to fix this.
> > > 
> > > This also adds a possibly useful error message if the negotiation fails
> > > (i.e. if there isn't a CPU mode that's suitable for both guest and host).
> > > 
> > > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > > Reviewed-by: Laurent Vivier <lvivier@redhat.com>
> > > Reviewed-by: Greg Kurz <groug@kaod.org>
> > > ---  
> > 
> > Any reason for not seing these patches as well in this pull request ?
> > 
> > pseries: Restore PVR negotiation logic for  pre-2.9 machine types
> > pseries: Improve tracing of CPU  compatibility negotiation  
> 
> Yes.  After more discussion; and comparison with analogous x86 cases
> that came up with Igor's NUMA cleanups, I've decided that the
> behaviour here while guest visible comes under the heading of a
> firmware behaviour change, which we don't typically arrange 100%
> matching behaviour for.  Meanwhile, I also found out more things that
> suggest matching old behaviour correctly is going to be even messier
> than I though.
> 
> So, I've decided that leaving the behaviour change in place is the
> better course.  Note that it won't affect migration (at least after
> the other compat/migration fixes are merged).
> 
> I'll reconsider if we observe a real problem in the wild with it.
> 

Thanks for the detailed explanation!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]