[PATCH 1/2] powerpc/kexec: Reset secondary cpu endianess before kexec

[PATCH 1/2] powerpc/kexec: Reset secondary cpu endianess before kexec

[Samuel Mendoza-Jonas]

If the target kernel does not inlcude the FIXUP_ENDIAN check, coming
from a different-endian kernel will cause the target kernel to panic.
All ppc64 kernels can handle starting in big-endian mode, so return to
big-endian before branching into the target kernel.

This mainly affects pseries as secondaries on powernv are returned to
OPAL.

Signed-off-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
---
 arch/powerpc/kernel/misc_64.S | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index 4e314b9..c73e587 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -475,9 +475,20 @@ _GLOBAL(kexec_wait)
 #ifdef CONFIG_KEXEC		/* use no memory without kexec */
 	lwz	r4,0(r5)
 	cmpwi	0,r4,0
-	bnea	0x60
+	beq	99b
+	mfmsr	r9		/* Check endianess */
+	clrldi.	r10,r9,63
+	beqa	0x60		/* Already big-endian */
+	bcl	20,31,$+4
+	mflr	r10
+	addi	r10,r10,28
+	mfmsr	r11
+	xori	r11,r11,1
+	mtsrr0	r10
+	mtsrr1	r11
+	rfid
+	.long	0x62000048	/* ba 0x60 */
 #endif
-	b	99b
 
 /* this can be in text because we won't change it until we are
  * running in real anyways
-- 
2.4.5

[PATCH 2/2] powerpc/kexec: Reset HILE before kexec_sequence

[Samuel Mendoza-Jonas]

On powernv secondary cpus are returned to OPAL, and will then enter the
target kernel in big-endian. However if it is set the HILE bit will persist,
causing the first exception in the target kernel to be delivered in
litte-endian regardless of the kernel endianess.
Make sure that the HILE bit is switched off before entering
kexec_sequence.

Signed-off-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
---
 arch/powerpc/kernel/machine_kexec_64.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
index 1a74446..2266135c 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -22,8 +22,10 @@
 #include <asm/page.h>
 #include <asm/current.h>
 #include <asm/machdep.h>
+#include <asm/opal.h>
 #include <asm/cacheflush.h>
 #include <asm/paca.h>
+#include <asm/firmware.h>
 #include <asm/mmu.h>
 #include <asm/sections.h>	/* _end */
 #include <asm/prom.h>
@@ -356,6 +358,10 @@ void default_machine_kexec(struct kimage *image)
 	 * switched to a static version!
 	 */
 
+	/* Reset HILE in case we kexec into an older BE kernel */
+	if (firmware_has_feature(FW_FEATURE_OPALv3))
+		opal_reinit_cpus(OPAL_REINIT_CPUS_HILE_BE);
+
 	/* Some things are best done in assembly.  Finding globals with
 	 * a toc is easier in C, so pass in what we can.
 	 */
-- 
2.4.5

Re: [PATCH 1/2] powerpc/kexec: Reset secondary cpu endianess before kexec

[Scott Wood]

On Wed, 2015-07-08 at 11:23 +1000, Samuel Mendoza-Jonas wrote:
> If the target kernel does not inlcude the FIXUP_ENDIAN check, coming
> from a different-endian kernel will cause the target kernel to panic.
> All ppc64 kernels can handle starting in big-endian mode, so return to
> big-endian before branching into the target kernel.
> 
> This mainly affects pseries as secondaries on powernv are returned to
> OPAL.
> 
> Signed-off-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
> ---
>  arch/powerpc/kernel/misc_64.S | 15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
> index 4e314b9..c73e587 100644
> --- a/arch/powerpc/kernel/misc_64.S
> +++ b/arch/powerpc/kernel/misc_64.S
> @@ -475,9 +475,20 @@ _GLOBAL(kexec_wait)
>  #ifdef CONFIG_KEXEC          /* use no memory without kexec */
>       lwz     r4,0(r5)
>       cmpwi   0,r4,0
> -     bnea    0x60
> +     beq     99b
> +     mfmsr   r9              /* Check endianess */
> +     clrldi. r10,r9,63
> +     beqa    0x60            /* Already big-endian */
> +     bcl     20,31,$+4
> +     mflr    r10
> +     addi    r10,r10,28
> +     mfmsr   r11
> +     xori    r11,r11,1
> +     mtsrr0  r10
> +     mtsrr1  r11
> +     rfid
> +     .long   0x62000048      /* ba 0x60 */
>  #endif
> -     b       99b

Could you put a book3s ifdef around this?  The low bit of MSR is reserved on 
book3e (and rfid doesn't exist).  Granted the bit should be zero, at least on 
FSL book3e, but it's better to be explicit about code that is subarch-
specific.

And yes, I have book3e kexec patches coming.

Also, it would be better to use label subtraction rather than hardcoding 
"28", and the bcl instruction would be more readable as "bl <label>".

-Scott

Re: [PATCH 1/2] powerpc/kexec: Reset secondary cpu endianess before kexec

[Paul Mackerras]

On Tue, Jul 07, 2015 at 09:35:38PM -0500, Scott Wood wrote:
> 
> Also, it would be better to use label subtraction rather than hardcoding 
> "28", and the bcl instruction would be more readable as "bl <label>".

I agree about using labels, but "bcl 20,31,foo" is not the same thing
as "bl foo".  The former is a form of bl that doesn't perturb the link
stack and is therefore better for performance when you're not going to
do a matching blr later (not that performance is at all critical
here).

Paul.

Re: [PATCH 1/2] powerpc/kexec: Reset secondary cpu endianess before kexec

[Scott Wood]

On Wed, 2015-07-08 at 14:04 +1000, Paul Mackerras wrote:
> On Tue, Jul 07, 2015 at 09:35:38PM -0500, Scott Wood wrote:
> > 
> > Also, it would be better to use label subtraction rather than hardcoding 
> > "28", and the bcl instruction would be more readable as "bl <label>".
> 
> I agree about using labels, but "bcl 20,31,foo" is not the same thing
> as "bl foo".  The former is a form of bl that doesn't perturb the link
> stack and is therefore better for performance when you're not going to
> do a matching blr later (not that performance is at all critical
> here).

If performance mattered I would have complained about the extra mfmsr. :-)

I see that some other parts of the kernel are using that bcl instruction, but 
if it is actually worthwhile in those places, it'd be nice to at least stick 
it in a macro for readability...

-Scott

Re: [PATCH 2/2] powerpc/kexec: Reset HILE before kexec_sequence

[Stewart Smith]

Samuel Mendoza-Jonas <sam.mj@au1.ibm.com> writes:
> On powernv secondary cpus are returned to OPAL, and will then enter the
> target kernel in big-endian. However if it is set the HILE bit will persist,
> causing the first exception in the target kernel to be delivered in
> litte-endian regardless of the kernel endianess.
> Make sure that the HILE bit is switched off before entering
> kexec_sequence.
>
> Signed-off-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>

Discussed with Sam on IRC, this makes kexec environment the same (or at
least closer to) booting the initial payload, which is a Good Thing(TM).

The ignoring of any error from opal_reinit_cpus() (as done in this
patch) is probably a good idea as we're either running on old firmware
which doesn't have the call (in which case we'd explode no matter what)
or we're on some crazy theoretical chip that doesn't do HILE=0, in which
case this gives us the best chance for compatibility.

Reviewed-by: Stewart Smith <stewart@linux.vnet.ibm.com>

Re: [PATCH 1/2] powerpc/kexec: Reset secondary cpu endianess before kexec

[Segher Boessenkool]

On Tue, Jul 07, 2015 at 11:22:08PM -0500, Scott Wood wrote:
> > I agree about using labels, but "bcl 20,31,foo" is not the same thing
> > as "bl foo".  The former is a form of bl that doesn't perturb the link
> > stack and is therefore better for performance when you're not going to
> > do a matching blr later (not that performance is at all critical
> > here).
> 
> If performance mattered I would have complained about the extra mfmsr. :-)
> 
> I see that some other parts of the kernel are using that bcl instruction, but 
> if it is actually worthwhile in those places, it'd be nice to at least stick 
> it in a macro for readability...

How is that going to help?  It's just idiom; replacing it with some other
idiom only means people already used to the 20,31 thing (which is quite old
by now, btw.; 74xx days) will have to learn the new thing.

Unless you can think of a nice short name that can even be made an extended
mnemonic?


Segher

Re: [PATCH 1/2] powerpc/kexec: Reset secondary cpu endianess before kexec

[Scott Wood]

On Thu, 2015-07-09 at 10:42 -0500, Segher Boessenkool wrote:
> On Tue, Jul 07, 2015 at 11:22:08PM -0500, Scott Wood wrote:
> > > I agree about using labels, but "bcl 20,31,foo" is not the same thing
> > > as "bl foo".  The former is a form of bl that doesn't perturb the link
> > > stack and is therefore better for performance when you're not going to
> > > do a matching blr later (not that performance is at all critical
> > > here).
> > 
> > If performance mattered I would have complained about the extra mfmsr. :-)
> > 
> > I see that some other parts of the kernel are using that bcl instruction, 
> > but 
> > if it is actually worthwhile in those places, it'd be nice to at least 
> > stick 
> > it in a macro for readability...
> 
> How is that going to help?  It's just idiom; replacing it with some other
> idiom only means people already used to the 20,31 thing (which is quite old
> by now, btw.; 74xx days) will have to learn the new thing.

That's fine for people who are used to it (especially if it's the only number-
based bc they routinely come across), but I had to look up what it meant.  
Simplified mnemonics exist for a reason.

> Unless you can think of a nice short name that can even be made an extended
> mnemonic?

For a macro I was thinking "BL_NORET" but for a mnemonic it'd probably be 
shortened to something like "blnr".

-Scott