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

[Greg Kurz]

On Wed, 31 May 2017 16:33:21 +1000
David Gibson <address@hidden> 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 <address@hidden> 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 <address@hidden>
> > > Reviewed-by: Laurent Vivier <address@hidden>
> > > Reviewed-by: Greg Kurz <address@hidden>
> > > ---  
> > 
> > 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!

pgpU3niOFvAyj.pgp
Description: OpenPGP digital signature