On Wed, 31 May 2017 16:33:21 +1000 David Gibson <da...@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 <da...@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 <da...@gibson.dropbear.id.au> > > > Reviewed-by: Laurent Vivier <lviv...@redhat.com> > > > Reviewed-by: Greg Kurz <gr...@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!
pgpb7SMj3jI7v.pgp
Description: OpenPGP digital signature
