[PATCH] powerpc/powernv: Return secondary CPUs to firmware on kexec

With OPAL v3 we can return secondary CPUs to firmware on kexec. This
allows firmware to do various cleanups making things generally more
reliable, and will enable the "new" kernel to call OPAL to perform
some reconfiguration tasks early on that can only be done while
all the CPUs are in firmware.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
index d4459bf..b59a1da 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c

@@ -31,6 +31,7 @@
 #include <asm/xics.h>
 #include <asm/rtas.h>
 #include <asm/opal.h>
+#include <asm/kexec.h>
 
 #include "powernv.h"
 

@@ -143,6 +144,16 @@ static void pnv_shutdown(void)
 static void pnv_kexec_cpu_down(int crash_shutdown, int secondary)
 {
 	xics_kexec_teardown_cpu(secondary);
+
+	/* Return secondary CPUs to firmware on OPAL v3 */
+	if (firmware_has_feature(FW_FEATURE_OPALv3) && secondary) {
+		mb();
+		get_paca()->kexec_state = KEXEC_STATE_REAL_MODE;
+		mb();
+
+		/* Return the CPU to OPAL */
+		opal_return_cpu();
+	}
 }
 #endif /* CONFIG_KEXEC */
 

With OPAL v3 we can return secondary CPUs to firmware on kexec. This
allows firmware to do various cleanups making things generally more
reliable, and will enable the "new" kernel to call OPAL to perform
some reconfiguration tasks early on that can only be done while
all the CPUs are in firmware.

Dumb question, but isn't the point of kexec to avoid fw interactions like
this?

Mikey

b/arch/powerpc/platforms/powernv/setup.c

On Fri, 2013-08-16 at 11:16 +1000, Michael Neuling wrote:

quoted

With OPAL v3 we can return secondary CPUs to firmware on kexec. This
allows firmware to do various cleanups making things generally more
reliable, and will enable the "new" kernel to call OPAL to perform
some reconfiguration tasks early on that can only be done while
all the CPUs are in firmware.

Dumb question, but isn't the point of kexec to avoid fw interactions
like this?

The point of kexec is to avoid rebooting :-)

Sending secondaries back to the OPAL internal spin loop doesn't take a
noticeable amount of time.

We could avoid doing it and solve the problem of needing all CPUs in
firmware for "reconfig" differently however. We could have the "target"
kernel code take them out of kexec into a special path that goes back
into the fw ... I chose the kexec solution because it was simpler and
less code :-)

Cheers,
Ben.

Mikey

quoted

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

diff --git a/arch/powerpc/platforms/powernv/setup.c

b/arch/powerpc/platforms/powernv/setup.c

quoted

index d4459bf..b59a1da 100644

--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c

@@ -31,6 +31,7 @@
 #include <asm/xics.h>
 #include <asm/rtas.h>
 #include <asm/opal.h>
+#include <asm/kexec.h>

 #include "powernv.h"

@@ -143,6 +144,16 @@ static void pnv_shutdown(void)
 static void pnv_kexec_cpu_down(int crash_shutdown, int secondary)
 {
        xics_kexec_teardown_cpu(secondary);
+
+       /* Return secondary CPUs to firmware on OPAL v3 */
+       if (firmware_has_feature(FW_FEATURE_OPALv3) && secondary) {
+               mb();
+               get_paca()->kexec_state = KEXEC_STATE_REAL_MODE;
+               mb();
+
+               /* Return the CPU to OPAL */
+               opal_return_cpu();
+       }
 }
 #endif /* CONFIG_KEXEC */

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org

4 more quoted lines