Skip to contentSkip to conversation

arm64: boot fixes/updates

PATCH New Mark Rutland 3 participants 14 messages Mar 13, 2015 – Mar 17, 2015 arm64

lore
Share & tools
lore

Mark Rutland

author reviewer
#0 lore raw

cover arm64: boot fixes/updates

Hi all,

The following patches address a few boot related issues I spotted recently.

The first patch fixes alternatives for !SMP kernels, the second fixes a potential issue with boot mode detection, and the final patches give us some better logging of the boot mode, fixing a latent bug in mismatch detection (though until now this has not been a problem).

Ard, Marc, I guess our recent boot patches are all going to clash. Do we need to sort that out between us or are we relying on the arm64 maintainers? ;)

Thanks,
Mark.

Mark Rutland (4):
arm64: apply alternatives for !SMP kernels
arm64: head.S: fix __boot_cpu_mode alignment
arm64: fix hyp mode mismatch detection
arm64: log CPU boot modes

 arch/arm64/Kconfig                |  4 ++++
 arch/arm64/include/asm/smp_plat.h |  2 ++
 arch/arm64/kernel/head.S          |  4 ++--
 arch/arm64/kernel/setup.c         | 25 +++++++++++++++++++++++++
 arch/arm64/kernel/smp.c           |  2 +-
 5 files changed, 34 insertions(+), 3 deletions(-)
Signature · 1 line
1.9.1
author reviewer
#1 lore raw

PATCH 1/4 arm64: apply alternatives for !SMP kernels

Currently we only perform alternative patching for kernels built with CONFIG_SMP, as we call apply_alternatives_all() in smp.c, which is only built for CONFIG_SMP. Thus !SMP kernels may not have necessary alternatives patched in.

This patch ensures that we call apply_alternatives_all() once all CPUs are booted, even for !SMP kernels, by having the smp_init_cpus() stub call this for !SMP kernels via up_late_init. A new wrapper, do_post_cpus_up_work, is added so we can hook other calls here later (e.g. boot mode logging).

Fixes e039ee4ee3fcf174 ("arm64: add alternative runtime patching")
Cc Andre Przywara <[email protected]>
Cc Will Deacon <[email protected]>
Cc Catalin Marinas <[email protected]>
---
 arch/arm64/Kconfig                |  4 ++++
 arch/arm64/include/asm/smp_plat.h |  2 ++
 arch/arm64/kernel/setup.c         | 12 ++++++++++++
 arch/arm64/kernel/smp.c           |  2 +-
 4 files changed, 19 insertions(+), 1 deletion(-)
arch/arm64/Kconfig +4 -0
index 1b8e973..0d46deb 100644
@@ -470,6 +470,10 @@ config HOTPLUG_CPU
 
 source kernel/Kconfig.preempt
 
+config UP_LATE_INIT
+       def_bool y
+       depends on !SMP
+
 config HZ
 	int
 	default 100
arch/arm64/include/asm/smp_plat.h +2 -0
index 59e2823..8dcd61e 100644
@@ -40,4 +40,6 @@ static inline u32 mpidr_hash_size(void)
 extern u64 __cpu_logical_map[NR_CPUS];
 #define cpu_logical_map(cpu)    __cpu_logical_map[cpu]
 
+void __init do_post_cpus_up_work(void);
+
 #endif /* __ASM_SMP_PLAT_H */
arch/arm64/kernel/setup.c +12 -0
index e8420f6..781f469 100644
@@ -207,6 +207,18 @@ static void __init smp_build_mpidr_hash(void)
 }
 #endif
 
+void __init do_post_cpus_up_work(void)
+{
+	apply_alternatives_all();
+}
+
+#ifdef CONFIG_UP_LATE_INIT
+void __init up_late_init(void)
+{
+	do_post_cpus_up_work();
+}
+#endif /* CONFIG_UP_LATE_INIT */
+
 static void __init setup_processor(void)
 {
 	struct cpu_info *cpu_info;
arch/arm64/kernel/smp.c +1 -1
index 328b8ce..4257369 100644
@@ -309,7 +309,7 @@ void cpu_die(void)
 void __init smp_cpus_done(unsigned int max_cpus)
 {
 	pr_info("SMP: Total of %d processors activated.\n", num_online_cpus());
-	apply_alternatives_all();
+	do_post_cpus_up_work();
 }
 
 void __init smp_prepare_boot_cpu(void)
Signature · 1 line
1.9.1
#2 lore raw

PATCH 1/4 arm64: apply alternatives for !SMP kernels

Quoted 11 lines · Mark Rutland

Currently we only perform alternative patching for kernels built with CONFIG_SMP, as we call apply_alternatives_all() in smp.c, which is only built for CONFIG_SMP. Thus !SMP kernels may not have necessary alternatives patched in.

This patch ensures that we call apply_alternatives_all() once all CPUs are booted, even for !SMP kernels, by having the smp_init_cpus() stub call this for !SMP kernels via up_late_init. A new wrapper, do_post_cpus_up_work, is added so we can hook other calls here later (e.g. boot mode logging).

Quoted 5 lines
Fixes e039ee4ee3fcf174 ("arm64: add alternative runtime patching")
Cc Andre Przywara <[email protected]>
Cc Will Deacon <[email protected]>
Cc Catalin Marinas <[email protected]>
Quoted 72 lines
---
 arch/arm64/Kconfig                |  4 ++++
 arch/arm64/include/asm/smp_plat.h |  2 ++
 arch/arm64/kernel/setup.c         | 12 ++++++++++++
 arch/arm64/kernel/smp.c           |  2 +-
 4 files changed, 19 insertions(+), 1 deletion(-)
arch/arm64/Kconfig +4 -0
index 1b8e973..0d46deb 100644
@@ -470,6 +470,10 @@ config HOTPLUG_CPU
 
 source kernel/Kconfig.preempt
 
+config UP_LATE_INIT
+       def_bool y
+       depends on !SMP
+
 config HZ
        int
        default 100
arch/arm64/include/asm/smp_plat.h +2 -0
index 59e2823..8dcd61e 100644
@@ -40,4 +40,6 @@ static inline u32 mpidr_hash_size(void)
 extern u64 __cpu_logical_map[NR_CPUS];
 #define cpu_logical_map(cpu)    __cpu_logical_map[cpu]
 
+void __init do_post_cpus_up_work(void);
+
 #endif /* __ASM_SMP_PLAT_H */
arch/arm64/kernel/setup.c +12 -0
index e8420f6..781f469 100644
@@ -207,6 +207,18 @@ static void __init smp_build_mpidr_hash(void)
 }
 #endif
 
+void __init do_post_cpus_up_work(void)
+{
+       apply_alternatives_all();
+}
+
+#ifdef CONFIG_UP_LATE_INIT
+void __init up_late_init(void)
+{
+       do_post_cpus_up_work();
+}
+#endif /* CONFIG_UP_LATE_INIT */
+
 static void __init setup_processor(void)
 {
        struct cpu_info *cpu_info;
arch/arm64/kernel/smp.c +1 -2
index 328b8ce..4257369 100644
@@ -309,7 +309,7 @@ void cpu_die(void)
 void __init smp_cpus_done(unsigned int max_cpus)
 {
        pr_info("SMP: Total of %d processors activated.\n", num_online_cpus());
-       apply_alternatives_all();
+       do_post_cpus_up_work();
 }
 
 void __init smp_prepare_boot_cpu(void)
--

1.9.1

author reviewer
#3 lore raw

PATCH 2/4 arm64: head.S: fix __boot_cpu_mode alignment

In reply to Mark Rutland

We currently align the allocation of the __boot_cpu_mode data _after_ allocating the label. Thus the label may point to padding before the data. While we seem to have gotten away with this so far, it's not a good idea to rely on any existing alignment in the object.

Perform the alignment padding before allocating the label to avoid this possibility.

Fixes c218bca74eeafa2f ("arm64: Relax the kernel cache requirements for boot")
Cc Catalin Marinas <[email protected]>
Cc Marc Zyngier <[email protected]>
Cc Will Deacon <[email protected]>
---
 arch/arm64/kernel/head.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/kernel/head.S +1 -1
index 8ce88e0..07f9305 100644
@@ -585,8 +585,8 @@ ENDPROC(set_cpu_boot_mode_flag)
  * zeroing of .bss would clobber it.
  */
 	.pushsection	.data..cacheline_aligned
-ENTRY(__boot_cpu_mode)
 	.align	L1_CACHE_SHIFT
+ENTRY(__boot_cpu_mode)
 	.long	BOOT_CPU_MODE_EL2
 	.long	0
 	.popsection
Signature · 1 line
1.9.1
author reviewer
#4 lore raw

PATCH 3/4 arm64: fix hyp mode mismatch detection

In reply to Mark Rutland

Commit 828e9834e9a5b7e6 ("arm64: head: create a new function for setting the boot_cpu_mode flag") added BOOT_CPU_MODE_EL1, a nonzero value replacing uses of zero. However it failed to update __boot_cpu_mode appropriately.

A CPU booted at EL2 writes BOOT_CPU_MODE_EL2 to __boot_cpu_mode[0], and a CPU booted at EL1 writes BOOT_CPU_MODE_EL1 to __boot_cpu_mode[1]. Later is_hyp_mode_mismatched() determines there to be a mismatch if __boot_cpu_mode[0] != __boot_cpu_mode[1].

If all CPUs are booted at EL1, __boot_cpu_mode[0] will be set to BOOT_CPU_MODE_EL1, but __boot_cpu_mode[1] will retain its initial value of zero, and is_hyp_mode_mismatched will erroneously determine that the boot modes are mismatched. This hasn't been a problem so far, but later patches which will make use of is_hyp_mode_mismatched() expect it to work correctly.

This patch initialises __boot_cpu_mode[1] to BOOT_CPU_MODE_EL1, fixing the erroneous mismatch detection when all CPUs are booted at EL1.

Cc Catalin Marinas <[email protected]>
Cc Marc Zyngier <[email protected]>
Cc Will Deacon <[email protected]>
---
 arch/arm64/kernel/head.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/kernel/head.S +1 -1
index 07f9305..d17649d 100644
@@ -588,7 +588,7 @@ ENDPROC(set_cpu_boot_mode_flag)
 	.align	L1_CACHE_SHIFT
 ENTRY(__boot_cpu_mode)
 	.long	BOOT_CPU_MODE_EL2
-	.long	0
+	.long	BOOT_CPU_MODE_EL1
 	.popsection
 
 #ifdef CONFIG_SMP
Signature · 1 line
1.9.1
#5 lore raw

PATCH 3/4 arm64: fix hyp mode mismatch detection

Quoted 17 lines · Mark Rutland

Commit 828e9834e9a5b7e6 ("arm64: head: create a new function for setting the boot_cpu_mode flag") added BOOT_CPU_MODE_EL1, a nonzero value replacing uses of zero. However it failed to update __boot_cpu_mode appropriately.

A CPU booted at EL2 writes BOOT_CPU_MODE_EL2 to __boot_cpu_mode[0], and a CPU booted at EL1 writes BOOT_CPU_MODE_EL1 to __boot_cpu_mode[1]. Later is_hyp_mode_mismatched() determines there to be a mismatch if __boot_cpu_mode[0] != __boot_cpu_mode[1].

If all CPUs are booted at EL1, __boot_cpu_mode[0] will be set to BOOT_CPU_MODE_EL1, but __boot_cpu_mode[1] will retain its initial value of zero, and is_hyp_mode_mismatched will erroneously determine that the boot modes are mismatched. This hasn't been a problem so far, but later patches which will make use of is_hyp_mode_mismatched() expect it to work correctly.

Quoted 3 lines

This patch initialises __boot_cpu_mode[1] to BOOT_CPU_MODE_EL1, fixing the erroneous mismatch detection when all CPUs are booted at EL1.

Maybe it's just me, but isn't it *much* easier to understand to initialise both values to 0, and use 'both are non-zero' as the error condition?
'HYP mode available' would then be '__boot_cpu_mode[0] == BOOT_CPU_MODE_EL2 && __boot_cpu_mode[1] == 0'

Quoted 24 lines
Cc Catalin Marinas <[email protected]>
Cc Marc Zyngier <[email protected]>
Cc Will Deacon <[email protected]>
---
 arch/arm64/kernel/head.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/kernel/head.S +1 -2
index 07f9305..d17649d 100644
@@ -588,7 +588,7 @@ ENDPROC(set_cpu_boot_mode_flag)
        .align  L1_CACHE_SHIFT
 ENTRY(__boot_cpu_mode)
        .long   BOOT_CPU_MODE_EL2
-       .long   0
+       .long   BOOT_CPU_MODE_EL1
        .popsection
 
 #ifdef CONFIG_SMP
--

1.9.1

author reviewer
#6 lore raw

PATCH 3/4 arm64: fix hyp mode mismatch detection

Quoted 22 lines · Ard Biesheuvel
Quoted 17 lines · Mark Rutland

Commit 828e9834e9a5b7e6 ("arm64: head: create a new function for setting the boot_cpu_mode flag") added BOOT_CPU_MODE_EL1, a nonzero value replacing uses of zero. However it failed to update __boot_cpu_mode appropriately.

A CPU booted at EL2 writes BOOT_CPU_MODE_EL2 to __boot_cpu_mode[0], and a CPU booted at EL1 writes BOOT_CPU_MODE_EL1 to __boot_cpu_mode[1]. Later is_hyp_mode_mismatched() determines there to be a mismatch if __boot_cpu_mode[0] != __boot_cpu_mode[1].

If all CPUs are booted at EL1, __boot_cpu_mode[0] will be set to BOOT_CPU_MODE_EL1, but __boot_cpu_mode[1] will retain its initial value of zero, and is_hyp_mode_mismatched will erroneously determine that the boot modes are mismatched. This hasn't been a problem so far, but later patches which will make use of is_hyp_mode_mismatched() expect it to work correctly.

Quoted 3 lines

This patch initialises __boot_cpu_mode[1] to BOOT_CPU_MODE_EL1, fixing the erroneous mismatch detection when all CPUs are booted at EL1.

Quoted 5 lines

Maybe it's just me, but isn't it *much* easier to understand to initialise both values to 0, and use 'both are non-zero' as the error condition?
'HYP mode available' would then be '__boot_cpu_mode[0] == BOOT_CPU_MODE_EL2 && __boot_cpu_mode[1] == 0'

I agree that change would make this easier to follow.

Marc, are you happy with Ard's proposed change?

Mark.

Quoted 25 lines
Quoted 24 lines
Cc Catalin Marinas <[email protected]>
Cc Marc Zyngier <[email protected]>
Cc Will Deacon <[email protected]>
---
 arch/arm64/kernel/head.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/kernel/head.S +1 -2
index 07f9305..d17649d 100644
@@ -588,7 +588,7 @@ ENDPROC(set_cpu_boot_mode_flag)
        .align  L1_CACHE_SHIFT
 ENTRY(__boot_cpu_mode)
        .long   BOOT_CPU_MODE_EL2
-       .long   0
+       .long   BOOT_CPU_MODE_EL1
        .popsection
 
 #ifdef CONFIG_SMP
--

1.9.1

#7 lore raw

PATCH 3/4 arm64: fix hyp mode mismatch detection

Quoted 29 lines · Mark Rutland
Quoted 22 lines · Ard Biesheuvel
Quoted 17 lines · Mark Rutland

Commit 828e9834e9a5b7e6 ("arm64: head: create a new function for setting the boot_cpu_mode flag") added BOOT_CPU_MODE_EL1, a nonzero value replacing uses of zero. However it failed to update __boot_cpu_mode appropriately.

A CPU booted at EL2 writes BOOT_CPU_MODE_EL2 to __boot_cpu_mode[0], and a CPU booted at EL1 writes BOOT_CPU_MODE_EL1 to __boot_cpu_mode[1]. Later is_hyp_mode_mismatched() determines there to be a mismatch if __boot_cpu_mode[0] != __boot_cpu_mode[1].

If all CPUs are booted at EL1, __boot_cpu_mode[0] will be set to BOOT_CPU_MODE_EL1, but __boot_cpu_mode[1] will retain its initial value of zero, and is_hyp_mode_mismatched will erroneously determine that the boot modes are mismatched. This hasn't been a problem so far, but later patches which will make use of is_hyp_mode_mismatched() expect it to work correctly.

Quoted 3 lines

This patch initialises __boot_cpu_mode[1] to BOOT_CPU_MODE_EL1, fixing the erroneous mismatch detection when all CPUs are booted at EL1.

Quoted 5 lines

Maybe it's just me, but isn't it *much* easier to understand to initialise both values to 0, and use 'both are non-zero' as the error condition?
'HYP mode available' would then be '__boot_cpu_mode[0] == BOOT_CPU_MODE_EL2 && __boot_cpu_mode[1] == 0'

Quoted 3 lines

I agree that change would make this easier to follow.

Marc, are you happy with Ard's proposed change?

Absolutely. If that makes it more obvious, please go for it.

Thanks,

	M.
Signature · 1 line
Jazz is not dead. It just smells funny...
#8 lore raw

PATCH 3/4 arm64: fix hyp mode mismatch detection

Quoted 30 lines · Marc Zyngier
Quoted 29 lines · Mark Rutland
Quoted 27 lines · Ard Biesheuvel
Quoted 17 lines · Mark Rutland

Commit 828e9834e9a5b7e6 ("arm64: head: create a new function for setting the boot_cpu_mode flag") added BOOT_CPU_MODE_EL1, a nonzero value replacing uses of zero. However it failed to update __boot_cpu_mode appropriately.

A CPU booted at EL2 writes BOOT_CPU_MODE_EL2 to __boot_cpu_mode[0], and a CPU booted at EL1 writes BOOT_CPU_MODE_EL1 to __boot_cpu_mode[1]. Later is_hyp_mode_mismatched() determines there to be a mismatch if __boot_cpu_mode[0] != __boot_cpu_mode[1].

If all CPUs are booted at EL1, __boot_cpu_mode[0] will be set to BOOT_CPU_MODE_EL1, but __boot_cpu_mode[1] will retain its initial value of zero, and is_hyp_mode_mismatched will erroneously determine that the boot modes are mismatched. This hasn't been a problem so far, but later patches which will make use of is_hyp_mode_mismatched() expect it to work correctly.

Quoted 3 lines

This patch initialises __boot_cpu_mode[1] to BOOT_CPU_MODE_EL1, fixing the erroneous mismatch detection when all CPUs are booted at EL1.

Maybe it's just me, but isn't it *much* easier to understand to initialise both values to 0, and use 'both are non-zero' as the error condition?
'HYP mode available' would then be '__boot_cpu_mode[0] == BOOT_CPU_MODE_EL2 && __boot_cpu_mode[1] == 0'

Quoted 7 lines
Quoted 3 lines

I agree that change would make this easier to follow.

Marc, are you happy with Ard's proposed change?

Absolutely. If that makes it more obvious, please go for it.

OK, thanks

Actually, simply checking for __boot_cpu_mode[1] == 0 (i.e., no CPUs booted at EL1) would be sufficient to implement 'is HYP mode available'.

#9 lore raw

PATCH 3/4 arm64: fix hyp mode mismatch detection

In reply to Mark Rutland
Quoted 17 lines · Mark Rutland

Commit 828e9834e9a5b7e6 ("arm64: head: create a new function for setting the boot_cpu_mode flag") added BOOT_CPU_MODE_EL1, a nonzero value replacing uses of zero. However it failed to update __boot_cpu_mode appropriately.

A CPU booted at EL2 writes BOOT_CPU_MODE_EL2 to __boot_cpu_mode[0], and a CPU booted at EL1 writes BOOT_CPU_MODE_EL1 to __boot_cpu_mode[1]. Later is_hyp_mode_mismatched() determines there to be a mismatch if __boot_cpu_mode[0] != __boot_cpu_mode[1].

If all CPUs are booted at EL1, __boot_cpu_mode[0] will be set to BOOT_CPU_MODE_EL1, but __boot_cpu_mode[1] will retain its initial value of zero, and is_hyp_mode_mismatched will erroneously determine that the boot modes are mismatched. This hasn't been a problem so far, but later patches which will make use of is_hyp_mode_mismatched() expect it to work correctly.

Quoted 7 lines

This patch initialises __boot_cpu_mode[1] to BOOT_CPU_MODE_EL1, fixing the erroneous mismatch detection when all CPUs are booted at EL1.

Cc Catalin Marinas <[email protected]>
Cc Marc Zyngier <[email protected]>
Cc Will Deacon <[email protected]>
Quoted 20 lines
---
 arch/arm64/kernel/head.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/kernel/head.S +1 -2
index 07f9305..d17649d 100644
@@ -588,7 +588,7 @@ ENDPROC(set_cpu_boot_mode_flag)
        .align  L1_CACHE_SHIFT
 ENTRY(__boot_cpu_mode)
        .long   BOOT_CPU_MODE_EL2
-       .long   0
+       .long   BOOT_CPU_MODE_EL1
        .popsection
 
 #ifdef CONFIG_SMP
--

1.9.1

author reviewer
#10 lore raw

PATCH 4/4 arm64: log CPU boot modes

In reply to Mark Rutland

We currently don't log the boot mode for arm64 as we do for arm, and without KVM the user is provided with no indication as to which mode(s) CPUs were booted in, which can seriously hinder debugging in some cases.

Add logging to the boot path once all CPUs are up. Where CPUs are mismatched in violation of the boot protocol, WARN and set a taint (as we do for CPU other CPU feature mismatches) given that the firmware/bootloader is buggy and should be fixed.

Cc Catalin Marinas <[email protected]>
Cc Marc Zyngier <[email protected]>
Cc Will Deacon <[email protected]>
---
 arch/arm64/kernel/setup.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)
arch/arm64/kernel/setup.c +13 -0
index 781f469..1480894 100644
@@ -62,6 +62,7 @@
 #include <asm/memblock.h>
 #include <asm/psci.h>
 #include <asm/efi.h>
+#include <asm/virt.h>
 
 unsigned int processor_id;
 EXPORT_SYMBOL(processor_id);
@@ -207,8 +208,20 @@ static void __init smp_build_mpidr_hash(void)
 }
 #endif
 
+static void __init hyp_mode_check(void)
+{
+	if (is_hyp_mode_available())
+		pr_info("CPU: All CPU(s) started at EL2\n");
+	else if (is_hyp_mode_mismatched())
+		WARN_TAINT(1, TAINT_CPU_OUT_OF_SPEC,
+			   "CPU: CPUs started in inconsistent modes");
+	else
+		pr_info("CPU: All CPU(s) started at EL1\n");
+}
+
 void __init do_post_cpus_up_work(void)
 {
+	hyp_mode_check();
 	apply_alternatives_all();
 }
 
Signature · 1 line
1.9.1
#11 lore raw

PATCH 4/4 arm64: log CPU boot modes

Quoted 9 lines · Mark Rutland

We currently don't log the boot mode for arm64 as we do for arm, and without KVM the user is provided with no indication as to which mode(s) CPUs were booted in, which can seriously hinder debugging in some cases.

Add logging to the boot path once all CPUs are up. Where CPUs are mismatched in violation of the boot protocol, WARN and set a taint (as we do for CPU other CPU feature mismatches) given that the firmware/bootloader is buggy and should be fixed.

Quoted 4 lines
Cc Catalin Marinas <[email protected]>
Cc Marc Zyngier <[email protected]>
Cc Will Deacon <[email protected]>
Quoted 40 lines
---
 arch/arm64/kernel/setup.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)
arch/arm64/kernel/setup.c +13 -1
index 781f469..1480894 100644
@@ -62,6 +62,7 @@
 #include <asm/memblock.h>
 #include <asm/psci.h>
 #include <asm/efi.h>
+#include <asm/virt.h>
 
 unsigned int processor_id;
 EXPORT_SYMBOL(processor_id);
@@ -207,8 +208,20 @@ static void __init smp_build_mpidr_hash(void)
 }
 #endif
 
+static void __init hyp_mode_check(void)
+{
+       if (is_hyp_mode_available())
+               pr_info("CPU: All CPU(s) started at EL2\n");
+       else if (is_hyp_mode_mismatched())
+               WARN_TAINT(1, TAINT_CPU_OUT_OF_SPEC,
+                          "CPU: CPUs started in inconsistent modes");
+       else
+               pr_info("CPU: All CPU(s) started at EL1\n");
+}
+
 void __init do_post_cpus_up_work(void)
 {
+       hyp_mode_check();
        apply_alternatives_all();
 }
 
--

1.9.1

#12 lore raw

cover arm64: boot fixes/updates

In reply to Mark Rutland
Quoted 5 lines · Mark Rutland

Hi all,

The following patches address a few boot related issues I spotted recently.

Quoted 9 lines

The first patch fixes alternatives for !SMP kernels, the second fixes a potential issue with boot mode detection, and the final patches give us some better logging of the boot mode, fixing a latent bug in mismatch detection (though until now this has not been a problem).

Ard, Marc, I guess our recent boot patches are all going to clash. Do we need to sort that out between us or are we relying on the arm64 maintainers? ;)

Seems we spotted and fixed the same bug at the same time :-) (but I failed to put you on cc)

http://article.gmane.org/gmane.linux.ports.arm.kernel/400100

I can stick all of our patches on a branch for Will to pull, if people are ok with that?
I need another couple of acks though

Signature · 1 line
Ard.
Quoted 16 lines

Mark Rutland (4):
arm64: apply alternatives for !SMP kernels
arm64: head.S: fix __boot_cpu_mode alignment
arm64: fix hyp mode mismatch detection
arm64: log CPU boot modes

 arch/arm64/Kconfig                |  4 ++++
 arch/arm64/include/asm/smp_plat.h |  2 ++
 arch/arm64/kernel/head.S          |  4 ++--
 arch/arm64/kernel/setup.c         | 25 +++++++++++++++++++++++++
 arch/arm64/kernel/smp.c           |  2 +-
 5 files changed, 34 insertions(+), 3 deletions(-)

--
1.9.1

author reviewer
#13 lore raw

cover arm64: boot fixes/updates

Quoted 16 lines · Ard Biesheuvel
Quoted 5 lines · Mark Rutland

Hi all,

The following patches address a few boot related issues I spotted recently.

Quoted 9 lines

The first patch fixes alternatives for !SMP kernels, the second fixes a potential issue with boot mode detection, and the final patches give us some better logging of the boot mode, fixing a latent bug in mismatch detection (though until now this has not been a problem).

Ard, Marc, I guess our recent boot patches are all going to clash. Do we need to sort that out between us or are we relying on the arm64 maintainers? ;)

Quoted 4 lines

Seems we spotted and fixed the same bug at the same time :-) (but I failed to put you on cc)

http://article.gmane.org/gmane.linux.ports.arm.kernel/400100

Haha. Your patch looks good to me, so I've given it my Ack. :)

Quoted 2 lines

I can stick all of our patches on a branch for Will to pull, if people are ok with that?

That sounds fine by me.

Quoted 1 line

I need another couple of acks though

Understood.

Mark.