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 instead. The same happens with current master + your patches applied on top. I'm not sure how much real trouble that will actually cause for guests, but it's a guest-visible change as a result of upgrading QEMU, which should just not happen. I'll keep testing your series and get back to you as soon as I have more feedback or questions. -- Andrea Bolognani / Red Hat / Virtualization
