]> git.proxmox.com Git - mirror_qemu.git/commit
spapr: fix device tree properties when using compatibility mode
authorGreg Kurz <groug@kaod.org>
Wed, 17 Jan 2018 09:20:42 +0000 (10:20 +0100)
committerMichael Roth <mdroth@linux.vnet.ibm.com>
Tue, 6 Feb 2018 00:55:26 +0000 (18:55 -0600)
commit4374cbca952851b92ec2532041f7557d959dbd23
tree237a34ddae02e4efe36b7bbbc9a3c4869b224499
parenta1f33a5b93f75abfdbaf4023cf9b7935285a705f
spapr: fix device tree properties when using compatibility mode

Commit 51f84465dd98 changed the compatility mode setting logic:
- machine reset only sets compatibility mode for the boot CPU
- compatibility mode is set for other CPUs when they are put online
  by the guest with the "start-cpu" RTAS call

This causes a regression for machines started with max-compat-cpu:
the device tree nodes related to secondary CPU cores contain wrong
"cpu-version" and "ibm,pa-features" values, as shown below.

Guest started on a POWER8 host with:
     -smp cores=2 -machine pseries,max-cpu-compat=compat7

                        ibm,pa-features = [18 00 f6 3f c7 c0 80 f0 80 00
 00 00 00 00 00 00 00 00 80 00 80 00 80 00 00 00];
                        cpu-version = <0x4d0200>;

                               ^^^
                        second CPU core

                        ibm,pa-features = <0x600f63f 0xc70080c0>;
                        cpu-version = <0xf000003>;

                               ^^^
                          boot CPU core

The second core is advertised in raw POWER8 mode. This happens because
CAS assumes all CPUs to have the same compatibility mode. Since the
boot CPU already has the requested compatibility mode, the CAS code
does not set it for the secondary one, and exposes the bogus device
tree properties in in the CAS response to the guest.

A similar situation is observed when hot-plugging a CPU core. The
related device tree properties are generated and exposed to guest
with the "ibm,configure-connector" RTAS before "start-cpu" is called.
The CPU core is advertised to the guest in raw mode as well.

It both cases, it boils down to the fact that "start-cpu" happens too
late. This can be fixed globally by propagating the compatibility mode
of the boot CPU to the other CPUs during reset.  For this to work, the
compatibility mode of the boot CPU must be set before the machine code
actually resets all CPUs.

It is not needed to set the compatibility mode in "start-cpu" anymore,
so the code is dropped.

Fixes: 51f84465dd98
Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 9012a53f067a78022947e18050b145c34a3dc599)
 Conflicts:
hw/ppc/spapr_cpu_core.c
hw/ppc/spapr_rtas.c
* drop context dep on d6322252b32
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
hw/ppc/spapr.c
hw/ppc/spapr_cpu_core.c