Re: [Qemu-ppc] [PATCH] spapr: add "compat" machine option

From:

Paul Mackerras

Subject:

Re: [Qemu-ppc] [PATCH] spapr: add "compat" machine option

Date:

Wed, 6 Nov 2013 14:27:20 +1100

User-agent:

Mutt/1.5.21 (2010-09-15)

On Tue, Nov 05, 2013 at 10:06:04AM +0100, Paolo Bonzini wrote:
> Il 30/09/2013 14:57, Alexey Kardashevskiy ha scritto:
> >> > Why is the option under -machine instead of -cpu?
> > Because it is still the same CPU and the guest will still read the real
> > PVR from the hardware (which it may not support but this is why we need
> > compatibility mode).
>
> How do you support migration from a newer to an older CPU then?
PowerVM has supported this for years, so there are well-established
interfaces that existing guest kernels use for this.
Basically, the hypervisor can put the CPU into a mode where the
processor behaves when in user mode according to an earlier version of
the architecture. POWER8 conforms to architecture 2.07, and it has a
register with bits that allow it to be put into an architecture 2.05
(POWER6) mode or an architecture 2.06 (POWER7) mode. In 2.05 mode,
none of the instructions and registers that are new in POWER7 and
POWER8 are available in user mode, and in 2.06 mode, none of the
facilities that are new in POWER8 are available in user mode.
The other thing the hypervisor does is tell the guest which
architecture mode the CPU is running in via a property in the device
tree. Linux kernels use that to determine the list of hardware
features that they can use.
Under PowerVM, if you are running a guest on a POWER8 (say) and you
want to be able to be able to migrate to a POWER6 later on, you have
to run the guest in architecture 2.05 mode, even if the guest knows
about later architecture versions.
> I think
> the guest should never see anything about the hardware CPU model.
The architecture doesn't let us do that, but our guest kernels are
accustomed to largely ignoring the actual PVR and operating on the
basis of the architecture level that we tell them via the device
tree.
Regards,
Paul.