Re: [Qemu-devel] [PATCHv3 0/4] Clean up compatibility mode handling

[Andrea Bolognani <abologna@redhat.com>]

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