[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-ppc] [PATCHv3 0/4] Clean up compatibility mode ha
From: |
Greg Kurz |
Subject: |
Re: [Qemu-devel] [Qemu-ppc] [PATCHv3 0/4] Clean up compatibility mode handling |
Date: |
Thu, 4 May 2017 21:22:37 +0200 |
On Thu, 04 May 2017 16:32:59 +0200
Andrea Bolognani <address@hidden> wrote:
> 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
>
The goal of this series is indeed to switch from raw to architected but I
agree that it shouldn't affect existing machine types. This probably calls
for some compat prop.
> 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
>
pgpUiVgYnsJzk.pgp
Description: OpenPGP digital signature