[qemu-xen master] spapr: fix device tree properties when using compatibility mode

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[qemu-xen master] spapr: fix device tree properties when using compatibility mode

patchbot
commit 4374cbca952851b92ec2532041f7557d959dbd23
Author:     Greg Kurz <[hidden email]>
AuthorDate: Wed Jan 17 10:20:42 2018 +0100
Commit:     Michael Roth <[hidden email]>
CommitDate: Mon Feb 5 18:55:26 2018 -0600

    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 <[hidden email]>
    Signed-off-by: David Gibson <[hidden email]>
    (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 <[hidden email]>
---
 hw/ppc/spapr.c          | 18 +++++++++---------
 hw/ppc/spapr_cpu_core.c |  7 +++++++
 2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 3490573..6ab39a0 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1458,6 +1458,15 @@ static void ppc_spapr_reset(void)
         spapr_setup_hpt_and_vrma(spapr);
     }
 
+    /* if this reset wasn't generated by CAS, we should reset our
+     * negotiated options and start from scratch */
+    if (!spapr->cas_reboot) {
+        spapr_ovec_cleanup(spapr->ov5_cas);
+        spapr->ov5_cas = spapr_ovec_new();
+
+        ppc_set_compat(first_ppc_cpu, spapr->max_compat_pvr, &error_fatal);
+    }
+
     qemu_devices_reset();
 
     /* DRC reset may cause a device to be unplugged. This will cause troubles
@@ -1478,15 +1487,6 @@ static void ppc_spapr_reset(void)
     rtas_addr = rtas_limit - RTAS_MAX_SIZE;
     fdt_addr = rtas_addr - FDT_MAX_SIZE;
 
-    /* if this reset wasn't generated by CAS, we should reset our
-     * negotiated options and start from scratch */
-    if (!spapr->cas_reboot) {
-        spapr_ovec_cleanup(spapr->ov5_cas);
-        spapr->ov5_cas = spapr_ovec_new();
-
-        ppc_set_compat_all(spapr->max_compat_pvr, &error_fatal);
-    }
-
     fdt = spapr_build_fdt(spapr, rtas_addr, spapr->rtas_size);
 
     spapr_load_rtas(spapr, fdt, rtas_addr);
diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
index 3a4c174..e8b0ffb 100644
--- a/hw/ppc/spapr_cpu_core.c
+++ b/hw/ppc/spapr_cpu_core.c
@@ -35,6 +35,13 @@ static void spapr_cpu_reset(void *opaque)
     cs->halted = 1;
 
     env->spr[SPR_HIOR] = 0;
+
+    /* Set compatibility mode to match the boot CPU, which was either set
+     * by the machine reset code or by CAS. This should never fail.
+     */
+    if (cs != first_cpu) {
+        ppc_set_compat(cpu, POWERPC_CPU(first_cpu)->compat_pvr, &error_abort);
+    }
 }
 
 static void spapr_cpu_destroy(PowerPCCPU *cpu)
--
generated by git-patchbot for /home/xen/git/qemu-xen.git#master

_______________________________________________
Xen-changelog mailing list
[hidden email]
https://lists.xenproject.org/xen-changelog