On Mon, May 29, 2017 at 11:14:08PM +0200, Greg Kurz wrote: > On Thu, 25 May 2017 13:51:25 +1000 > David Gibson 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 > > Reviewed-by: Laurent Vivier > > Reviewed-by: Greg Kurz > > --- > > 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. -- 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