[PATCH v5 2/2] arm64: Add software workaround for Falkor erratum 1041
The ARM architecture defines the memory locations that are permitted
to be accessed as the result of a speculative instruction fetch from
an exception level for which all stages of translation are disabled.
Specifically, the core is permitted to speculatively fetch from the
4KB region containing the current program counter 4K and next 4K.
When translation is changed from enabled to disabled for the running
exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the
Falkor core may errantly speculatively access memory locations outside
of the 4KB region permitted by the architecture. The errant memory
access may lead to one of the following unexpected behaviors.
1) A System Error Interrupt (SEI) being raised by the Falkor core due
to the errant memory access attempting to access a region of memory
that is protected by a slave-side memory protection unit.
2) Unpredictable device behavior due to a speculative read from device
memory. This behavior may only occur if the instruction cache is
disabled prior to or coincident with translation being changed from
enabled to disabled.
The conditions leading to this erratum will not occur when either of the
following occur:
1) A higher exception level disables translation of a lower exception level
(e.g. EL2 changing SCTLR_EL1[M] from a value of 1 to 0).
2) An exception level disabling its stage-1 translation if its stage-2
translation is enabled (e.g. EL1 changing SCTLR_EL1[M] from a value of 1
to 0 when HCR_EL2[VM] has a value of 1).
To avoid the errant behavior, software must execute an ISB immediately
prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.
Signed-off-by: Shanker Donthineni
---
Changes since v3:
Rebased to kernel v4.15-rc3 and removed the alternatives.
Changes since v3:
Rebased to kernel v4.15-rc1.
Changes since v2:
Repost the corrected patches.
Changes since v1:
Apply the workaround where it's required.
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 12 +++-
arch/arm64/include/asm/assembler.h | 10 ++
arch/arm64/kernel/cpu-reset.S | 1 +
arch/arm64/kernel/efi-entry.S | 2 ++
arch/arm64/kernel/head.S | 1 +
arch/arm64/kernel/relocate_kernel.S| 1 +
arch/arm64/kvm/hyp-init.S | 1 +
8 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/Documentation/arm64/silicon-errata.txt
b/Documentation/arm64/silicon-errata.txt
index 304bf22..fc1c884 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -75,3 +75,4 @@ stable kernels.
| Qualcomm Tech. | Falkor v1 | E1003 |
QCOM_FALKOR_ERRATUM_1003|
| Qualcomm Tech. | Falkor v1 | E1009 |
QCOM_FALKOR_ERRATUM_1009|
| Qualcomm Tech. | QDF2400 ITS | E0065 |
QCOM_QDF2400_ERRATUM_0065 |
+| Qualcomm Tech. | Falkor v{1,2} | E1041 |
QCOM_FALKOR_ERRATUM_1041|
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index a93339f..c9a7e9e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -557,7 +557,6 @@ config QCOM_QDF2400_ERRATUM_0065
If unsure, say Y.
-
config SOCIONEXT_SYNQUACER_PREITS
bool "Socionext Synquacer: Workaround for GICv3 pre-ITS"
default y
@@ -576,6 +575,17 @@ config HISILICON_ERRATUM_161600802
a 128kB offset to be applied to the target address in this commands.
If unsure, say Y.
+
+config QCOM_FALKOR_ERRATUM_E1041
+ bool "Falkor E1041: Speculative instruction fetches might cause errant
memory access"
+ default y
+ help
+ Falkor CPU may speculatively fetch instructions from an improper
+ memory location when MMU translation is changed from SCTLR_ELn[M]=1
+ to SCTLR_ELn[M]=0. Prefix an ISB instruction to fix the problem.
+
+ If unsure, say Y.
+
endmenu
diff --git a/arch/arm64/include/asm/assembler.h
b/arch/arm64/include/asm/assembler.h
index aef72d8..8b16828 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -512,4 +512,14 @@
#endif
.endm
+/**
+ * Errata workaround prior to disable MMU. Insert an ISB immediately prior
+ * to executing the MSR that will change SCTLR_ELn[M] from a value of 1 to 0.
+ */
+ .macro pre_disable_mmu_workaround
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
+ isb
+#endif
+ .endm
+
#endif /* __ASM_ASSEMBLER_H */
diff --git a/arch/arm64/kernel/cpu-reset.S b/arch/arm64/kernel/cpu-reset.S
index 65f42d2..2a752cb 100644
--- a/arch/arm64/kernel/cpu-reset.S
+++ b/arch/arm64/kernel/cpu-reset.S
@@ -37,6 +37,7 @@ ENTRY(__cpu_soft_restart)
mrs x12, sctlr_el1
ldr x13, =SCTLR_ELx_FLAGS
bic x12, x12, x13
+ pre_disable_mmu_workaround
msr sctlr_el1, x12
isb
diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry
[PATCH v5 1/2] arm64: Define cputype macros for Falkor CPU
Add cputype definition macros for Qualcomm Datacenter Technologies Falkor CPU in cputype.h. It's unfortunate that the first revision of the Falkor CPU used the wrong part number 0x800, got fixed in v2 chip with part number 0xC00, and would be used the same value for future revisions. Signed-off-by: Shanker Donthineni --- arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h index 235e77d..cbf08d7 100644 --- a/arch/arm64/include/asm/cputype.h +++ b/arch/arm64/include/asm/cputype.h @@ -91,6 +91,7 @@ #define BRCM_CPU_PART_VULCAN 0x516 #define QCOM_CPU_PART_FALKOR_V10x800 +#define QCOM_CPU_PART_FALKOR 0xC00 #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53) #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57) @@ -99,6 +100,7 @@ #define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX) #define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX) #define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR_V1) +#define MIDR_QCOM_FALKOR MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR) #ifndef __ASSEMBLY__ -- Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v4 2/2] arm64: Add software workaround for Falkor erratum 1041
Thanks Mark, I'll post v5 patch without alternatives. On 12/11/2017 04:45 AM, Mark Rutland wrote: > Hi, > > On Sun, Dec 10, 2017 at 08:03:43PM -0600, Shanker Donthineni wrote: >> +/** >> + * Errata workaround prior to disable MMU. Insert an ISB immediately prior >> + * to executing the MSR that will change SCTLR_ELn[M] from a value of 1 to >> 0. >> + */ >> +.macro pre_disable_mmu_workaround >> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041 >> +alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1041 >> +isb >> +alternative_else_nop_endif >> +#endif >> +.endm > > There's really no need for this to be an alternative. It makes the > kernel larger and more complex due to all the altinstr data and probing > code. > > As Will suggested last time [1], please just use the ifdef, and always > compile-in the extra ISB if CONFIG_QCOM_FALKOR_ERRATUM_E1041 is > selected. Get rid of the alternatives and probing code. > > All you need here is: > > /* >* Some Falkor parts make errant speculative instruction fetches >* when SCTLR_ELx.M is cleared. An ISB before the write to >* SCTLR_ELx prevents this. >*/ > .macro pre_disable_mmu_workaround > #ifdef > isb > #endif > .endm > >> + >> +.macro pre_disable_mmu_early_workaround >> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041 >> +isb >> +#endif >> +.endm >> + > > ... and we don't need a special early variant. > > Thanks, > Mark. > > [1] https://lkml.kernel.org/r/20171201112457.ge18...@arm.com > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- Shanker Donthineni Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v4 1/2] arm64: Define cputype macros for Falkor CPU
Add cputype definition macros for Qualcomm Datacenter Technologies Falkor CPU in cputype.h. It's unfortunate that the first revision of the Falkor CPU used the wrong part number 0x800, got fixed in v2 chip with part number 0xC00, and would be used the same value for future revisions. Signed-off-by: Shanker Donthineni --- arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h index 235e77d..cbf08d7 100644 --- a/arch/arm64/include/asm/cputype.h +++ b/arch/arm64/include/asm/cputype.h @@ -91,6 +91,7 @@ #define BRCM_CPU_PART_VULCAN 0x516 #define QCOM_CPU_PART_FALKOR_V10x800 +#define QCOM_CPU_PART_FALKOR 0xC00 #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53) #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57) @@ -99,6 +100,7 @@ #define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX) #define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX) #define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR_V1) +#define MIDR_QCOM_FALKOR MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR) #ifndef __ASSEMBLY__ -- Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v4 2/2] arm64: Add software workaround for Falkor erratum 1041
The ARM architecture defines the memory locations that are permitted
to be accessed as the result of a speculative instruction fetch from
an exception level for which all stages of translation are disabled.
Specifically, the core is permitted to speculatively fetch from the
4KB region containing the current program counter 4K and next 4K.
When translation is changed from enabled to disabled for the running
exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the
Falkor core may errantly speculatively access memory locations outside
of the 4KB region permitted by the architecture. The errant memory
access may lead to one of the following unexpected behaviors.
1) A System Error Interrupt (SEI) being raised by the Falkor core due
to the errant memory access attempting to access a region of memory
that is protected by a slave-side memory protection unit.
2) Unpredictable device behavior due to a speculative read from device
memory. This behavior may only occur if the instruction cache is
disabled prior to or coincident with translation being changed from
enabled to disabled.
The conditions leading to this erratum will not occur when either of the
following occur:
1) A higher exception level disables translation of a lower exception level
(e.g. EL2 changing SCTLR_EL1[M] from a value of 1 to 0).
2) An exception level disabling its stage-1 translation if its stage-2
translation is enabled (e.g. EL1 changing SCTLR_EL1[M] from a value of 1
to 0 when HCR_EL2[VM] has a value of 1).
To avoid the errant behavior, software must execute an ISB immediately
prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.
Signed-off-by: Shanker Donthineni
---
Changes since v3:
Rebased to kernel v4.15-rc1.
Changes since v2:
Repost the corrected patches.
Changes since v1:
Apply the workaround where it's required.
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 12 +++-
arch/arm64/include/asm/assembler.h | 19 +++
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/kernel/cpu-reset.S | 1 +
arch/arm64/kernel/cpu_errata.c | 16
arch/arm64/kernel/efi-entry.S | 2 ++
arch/arm64/kernel/head.S | 1 +
arch/arm64/kernel/relocate_kernel.S| 1 +
arch/arm64/kvm/hyp-init.S | 1 +
10 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/Documentation/arm64/silicon-errata.txt
b/Documentation/arm64/silicon-errata.txt
index 304bf22..fc1c884 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -75,3 +75,4 @@ stable kernels.
| Qualcomm Tech. | Falkor v1 | E1003 |
QCOM_FALKOR_ERRATUM_1003|
| Qualcomm Tech. | Falkor v1 | E1009 |
QCOM_FALKOR_ERRATUM_1009|
| Qualcomm Tech. | QDF2400 ITS | E0065 |
QCOM_QDF2400_ERRATUM_0065 |
+| Qualcomm Tech. | Falkor v{1,2} | E1041 |
QCOM_FALKOR_ERRATUM_1041|
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index a93339f..c9a7e9e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -557,7 +557,6 @@ config QCOM_QDF2400_ERRATUM_0065
If unsure, say Y.
-
config SOCIONEXT_SYNQUACER_PREITS
bool "Socionext Synquacer: Workaround for GICv3 pre-ITS"
default y
@@ -576,6 +575,17 @@ config HISILICON_ERRATUM_161600802
a 128kB offset to be applied to the target address in this commands.
If unsure, say Y.
+
+config QCOM_FALKOR_ERRATUM_E1041
+ bool "Falkor E1041: Speculative instruction fetches might cause errant
memory access"
+ default y
+ help
+ Falkor CPU may speculatively fetch instructions from an improper
+ memory location when MMU translation is changed from SCTLR_ELn[M]=1
+ to SCTLR_ELn[M]=0. Prefix an ISB instruction to fix the problem.
+
+ If unsure, say Y.
+
endmenu
diff --git a/arch/arm64/include/asm/assembler.h
b/arch/arm64/include/asm/assembler.h
index aef72d8..c77742a 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
.macro save_and_disable_daif, flags
mrs \flags, daif
@@ -512,4 +513,22 @@
#endif
.endm
+/**
+ * Errata workaround prior to disable MMU. Insert an ISB immediately prior
+ * to executing the MSR that will change SCTLR_ELn[M] from a value of 1 to 0.
+ */
+ .macro pre_disable_mmu_workaround
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
+alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1041
+ isb
+alternative_else_nop_endif
+#endif
+ .endm
+
+ .macro pre_disable_mmu_early_workaround
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
+ isb
+#endif
+ .endm
+
#endif /* __ASM_ASSEMBLER_H */
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
inde
Re: [PATCH v4 2/2] arm64: Add software workaround for Falkor erratum 1041
Hi Will, On 12/03/2017 07:35 AM, Shanker Donthineni wrote: > Hi Will, thanks for your review comments. > > On 12/01/2017 05:24 AM, Will Deacon wrote: >> On Mon, Nov 27, 2017 at 05:18:00PM -0600, Shanker Donthineni wrote: >>> The ARM architecture defines the memory locations that are permitted >>> to be accessed as the result of a speculative instruction fetch from >>> an exception level for which all stages of translation are disabled. >>> Specifically, the core is permitted to speculatively fetch from the >>> 4KB region containing the current program counter 4K and next 4K. >>> >>> When translation is changed from enabled to disabled for the running >>> exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the >>> Falkor core may errantly speculatively access memory locations outside >>> of the 4KB region permitted by the architecture. The errant memory >>> access may lead to one of the following unexpected behaviors. >>> >>> 1) A System Error Interrupt (SEI) being raised by the Falkor core due >>>to the errant memory access attempting to access a region of memory >>>that is protected by a slave-side memory protection unit. >>> 2) Unpredictable device behavior due to a speculative read from device >>>memory. This behavior may only occur if the instruction cache is >>>disabled prior to or coincident with translation being changed from >>>enabled to disabled. >>> >>> The conditions leading to this erratum will not occur when either of the >>> following occur: >>> 1) A higher exception level disables translation of a lower exception level >>>(e.g. EL2 changing SCTLR_EL1[M] from a value of 1 to 0). >>> 2) An exception level disabling its stage-1 translation if its stage-2 >>> translation is enabled (e.g. EL1 changing SCTLR_EL1[M] from a value of 1 >>> to 0 when HCR_EL2[VM] has a value of 1). >>> >>> To avoid the errant behavior, software must execute an ISB immediately >>> prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0. >>> >>> Signed-off-by: Shanker Donthineni >>> --- >>> Changes since v3: >>> Rebased to kernel v4.15-rc1. >>> Changes since v2: >>> Repost the corrected patches. >>> Changes since v1: >>> Apply the workaround where it's required. >>> >>> Documentation/arm64/silicon-errata.txt | 1 + >>> arch/arm64/Kconfig | 12 +++- >>> arch/arm64/include/asm/assembler.h | 19 +++ >>> arch/arm64/include/asm/cpucaps.h | 3 ++- >>> arch/arm64/kernel/cpu-reset.S | 1 + >>> arch/arm64/kernel/cpu_errata.c | 16 >>> arch/arm64/kernel/efi-entry.S | 2 ++ >>> arch/arm64/kernel/head.S | 1 + >>> arch/arm64/kernel/relocate_kernel.S| 1 + >>> arch/arm64/kvm/hyp-init.S | 1 + >> >> This is an awful lot of code just to add an ISB instruction prior to >> disabling the MMU. Why do you need to go through the alternatives framework >> for this? Just do it with an #ifdef; this isn't a fastpath. >> > > We can avoid changes to only two files cpu_errata.c and cpucaps.h without > using > the alternatives framework. Even though it's in slow path, cpu-errata.c > changes > provides a nice debug message which indicates the erratum E1041 is applied. > > Erratum log information would be very useful to conform our customers using > the > right kernel with E1014 patch by looking at dmesg. Other than that I don't > have > any other strong opinion to avoid alternatives and handle using #idef. > > Should I go ahead and post v5 patch without alternatives? > Please provide your thoughts on next step. We would like to merge this erratum to v4.15 kernel. >> Will >> >> ___ >> linux-arm-kernel mailing list >> linux-arm-ker...@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> > -- Shanker Donthineni Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] arm64: Add software workaround for Falkor erratum 1041
Hi Will, thanks for your review comments. On 12/01/2017 05:24 AM, Will Deacon wrote: > On Mon, Nov 27, 2017 at 05:18:00PM -0600, Shanker Donthineni wrote: >> The ARM architecture defines the memory locations that are permitted >> to be accessed as the result of a speculative instruction fetch from >> an exception level for which all stages of translation are disabled. >> Specifically, the core is permitted to speculatively fetch from the >> 4KB region containing the current program counter 4K and next 4K. >> >> When translation is changed from enabled to disabled for the running >> exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the >> Falkor core may errantly speculatively access memory locations outside >> of the 4KB region permitted by the architecture. The errant memory >> access may lead to one of the following unexpected behaviors. >> >> 1) A System Error Interrupt (SEI) being raised by the Falkor core due >>to the errant memory access attempting to access a region of memory >>that is protected by a slave-side memory protection unit. >> 2) Unpredictable device behavior due to a speculative read from device >>memory. This behavior may only occur if the instruction cache is >>disabled prior to or coincident with translation being changed from >>enabled to disabled. >> >> The conditions leading to this erratum will not occur when either of the >> following occur: >> 1) A higher exception level disables translation of a lower exception level >>(e.g. EL2 changing SCTLR_EL1[M] from a value of 1 to 0). >> 2) An exception level disabling its stage-1 translation if its stage-2 >> translation is enabled (e.g. EL1 changing SCTLR_EL1[M] from a value of 1 >> to 0 when HCR_EL2[VM] has a value of 1). >> >> To avoid the errant behavior, software must execute an ISB immediately >> prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0. >> >> Signed-off-by: Shanker Donthineni >> --- >> Changes since v3: >> Rebased to kernel v4.15-rc1. >> Changes since v2: >> Repost the corrected patches. >> Changes since v1: >> Apply the workaround where it's required. >> >> Documentation/arm64/silicon-errata.txt | 1 + >> arch/arm64/Kconfig | 12 +++- >> arch/arm64/include/asm/assembler.h | 19 +++ >> arch/arm64/include/asm/cpucaps.h | 3 ++- >> arch/arm64/kernel/cpu-reset.S | 1 + >> arch/arm64/kernel/cpu_errata.c | 16 >> arch/arm64/kernel/efi-entry.S | 2 ++ >> arch/arm64/kernel/head.S | 1 + >> arch/arm64/kernel/relocate_kernel.S| 1 + >> arch/arm64/kvm/hyp-init.S | 1 + > > This is an awful lot of code just to add an ISB instruction prior to > disabling the MMU. Why do you need to go through the alternatives framework > for this? Just do it with an #ifdef; this isn't a fastpath. > We can avoid changes to only two files cpu_errata.c and cpucaps.h without using the alternatives framework. Even though it's in slow path, cpu-errata.c changes provides a nice debug message which indicates the erratum E1041 is applied. Erratum log information would be very useful to conform our customers using the right kernel with E1014 patch by looking at dmesg. Other than that I don't have any other strong opinion to avoid alternatives and handle using #idef. Should I go head and post v5 patch without alternatives? > Will > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- Shanker Donthineni Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] arm64: Define cputype macros for Falkor CPU
Add cputype definition macros for Qualcomm Datacenter Technologies Falkor CPU in cputype.h. It's unfortunate that the first revision of the Falkor CPU used the wrong part number 0x800, got fixed in v2 chip with part number 0xC00, and would be used the same value for future revisions. Signed-off-by: Shanker Donthineni --- arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h index 235e77d..cbf08d7 100644 --- a/arch/arm64/include/asm/cputype.h +++ b/arch/arm64/include/asm/cputype.h @@ -91,6 +91,7 @@ #define BRCM_CPU_PART_VULCAN 0x516 #define QCOM_CPU_PART_FALKOR_V10x800 +#define QCOM_CPU_PART_FALKOR 0xC00 #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53) #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57) @@ -99,6 +100,7 @@ #define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX) #define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX) #define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR_V1) +#define MIDR_QCOM_FALKOR MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR) #ifndef __ASSEMBLY__ -- Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/2] arm64: Add software workaround for Falkor erratum 1041
The ARM architecture defines the memory locations that are permitted
to be accessed as the result of a speculative instruction fetch from
an exception level for which all stages of translation are disabled.
Specifically, the core is permitted to speculatively fetch from the
4KB region containing the current program counter 4K and next 4K.
When translation is changed from enabled to disabled for the running
exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the
Falkor core may errantly speculatively access memory locations outside
of the 4KB region permitted by the architecture. The errant memory
access may lead to one of the following unexpected behaviors.
1) A System Error Interrupt (SEI) being raised by the Falkor core due
to the errant memory access attempting to access a region of memory
that is protected by a slave-side memory protection unit.
2) Unpredictable device behavior due to a speculative read from device
memory. This behavior may only occur if the instruction cache is
disabled prior to or coincident with translation being changed from
enabled to disabled.
The conditions leading to this erratum will not occur when either of the
following occur:
1) A higher exception level disables translation of a lower exception level
(e.g. EL2 changing SCTLR_EL1[M] from a value of 1 to 0).
2) An exception level disabling its stage-1 translation if its stage-2
translation is enabled (e.g. EL1 changing SCTLR_EL1[M] from a value of 1
to 0 when HCR_EL2[VM] has a value of 1).
To avoid the errant behavior, software must execute an ISB immediately
prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.
Signed-off-by: Shanker Donthineni
---
Changes since v3:
Rebased to kernel v4.15-rc1.
Changes since v2:
Repost the corrected patches.
Changes since v1:
Apply the workaround where it's required.
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 12 +++-
arch/arm64/include/asm/assembler.h | 19 +++
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/kernel/cpu-reset.S | 1 +
arch/arm64/kernel/cpu_errata.c | 16
arch/arm64/kernel/efi-entry.S | 2 ++
arch/arm64/kernel/head.S | 1 +
arch/arm64/kernel/relocate_kernel.S| 1 +
arch/arm64/kvm/hyp-init.S | 1 +
10 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/Documentation/arm64/silicon-errata.txt
b/Documentation/arm64/silicon-errata.txt
index 304bf22..fc1c884 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -75,3 +75,4 @@ stable kernels.
| Qualcomm Tech. | Falkor v1 | E1003 |
QCOM_FALKOR_ERRATUM_1003|
| Qualcomm Tech. | Falkor v1 | E1009 |
QCOM_FALKOR_ERRATUM_1009|
| Qualcomm Tech. | QDF2400 ITS | E0065 |
QCOM_QDF2400_ERRATUM_0065 |
+| Qualcomm Tech. | Falkor v{1,2} | E1041 |
QCOM_FALKOR_ERRATUM_1041|
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index a93339f..c9a7e9e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -557,7 +557,6 @@ config QCOM_QDF2400_ERRATUM_0065
If unsure, say Y.
-
config SOCIONEXT_SYNQUACER_PREITS
bool "Socionext Synquacer: Workaround for GICv3 pre-ITS"
default y
@@ -576,6 +575,17 @@ config HISILICON_ERRATUM_161600802
a 128kB offset to be applied to the target address in this commands.
If unsure, say Y.
+
+config QCOM_FALKOR_ERRATUM_E1041
+ bool "Falkor E1041: Speculative instruction fetches might cause errant
memory access"
+ default y
+ help
+ Falkor CPU may speculatively fetch instructions from an improper
+ memory location when MMU translation is changed from SCTLR_ELn[M]=1
+ to SCTLR_ELn[M]=0. Prefix an ISB instruction to fix the problem.
+
+ If unsure, say Y.
+
endmenu
diff --git a/arch/arm64/include/asm/assembler.h
b/arch/arm64/include/asm/assembler.h
index aef72d8..c77742a 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
.macro save_and_disable_daif, flags
mrs \flags, daif
@@ -512,4 +513,22 @@
#endif
.endm
+/**
+ * Errata workaround prior to disable MMU. Insert an ISB immediately prior
+ * to executing the MSR that will change SCTLR_ELn[M] from a value of 1 to 0.
+ */
+ .macro pre_disable_mmu_workaround
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
+alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1041
+ isb
+alternative_else_nop_endif
+#endif
+ .endm
+
+ .macro pre_disable_mmu_early_workaround
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
+ isb
+#endif
+ .endm
+
#endif /* __ASM_ASSEMBLER_H */
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
inde
[PATCH v4 0/2] Implement a software workaround for Falkor erratum 1041
On Falkor CPU, we’ve discovered a hardware issue which might lead to a kernel crash or the unexpected behavior. The Falkor core may errantly access memory locations on speculative instruction fetches. This may happen whenever MMU translation state, SCTLR_ELn[M] bit is being changed from enabled to disabled for the currently running exception level. To prevent the errant hardware behavior, software must execute an ISB immediately prior to executing the MSR that changes SCTLR_ELn[M] from a value of 1 to 0. These v4 patches are based on 4.15-rc1 and tested on QDF2400 platform. Patch2 from V1 series got dropped to accommodate review comments. Apply the workaround where it's required. Posted wrong the patches in v2. Shanker Donthineni (2): arm64: Define cputype macros for Falkor CPU arm64: Add software workaround for Falkor erratum 1041 Documentation/arm64/silicon-errata.txt | 1 + arch/arm64/Kconfig | 12 +++- arch/arm64/include/asm/assembler.h | 19 +++ arch/arm64/include/asm/cpucaps.h | 3 ++- arch/arm64/include/asm/cputype.h | 2 ++ arch/arm64/kernel/cpu-reset.S | 1 + arch/arm64/kernel/cpu_errata.c | 16 arch/arm64/kernel/efi-entry.S | 2 ++ arch/arm64/kernel/head.S | 1 + arch/arm64/kernel/relocate_kernel.S| 1 + arch/arm64/kvm/hyp-init.S | 1 + 11 files changed, 57 insertions(+), 2 deletions(-) -- Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] arm64: Add software workaround for Falkor erratum 1041
Hi,
Sorry, I've posted a wrong patch which causes the compilation errors.
Please disregard this patch, I posted v3 patch to fix the build
issue.
https://patchwork.kernel.org/patch/10055077/
On 11/12/2017 07:16 PM, Shanker Donthineni wrote:
> The ARM architecture defines the memory locations that are permitted
> to be accessed as the result of a speculative instruction fetch from
> an exception level for which all stages of translation are disabled.
> Specifically, the core is permitted to speculatively fetch from the
> 4KB region containing the current program counter 4K and next 4K.
>
> When translation is changed from enabled to disabled for the running
> exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the
> Falkor core may errantly speculatively access memory locations outside
> of the 4KB region permitted by the architecture. The errant memory
> access may lead to one of the following unexpected behaviors.
>
> 1) A System Error Interrupt (SEI) being raised by the Falkor core due
>to the errant memory access attempting to access a region of memory
>that is protected by a slave-side memory protection unit.
> 2) Unpredictable device behavior due to a speculative read from device
>memory. This behavior may only occur if the instruction cache is
>disabled prior to or coincident with translation being changed from
>enabled to disabled.
>
> The conditions leading to this erratum will not occur when either of the
> following occur:
> 1) A higher exception level disables translation of a lower exception level
>(e.g. EL2 changing SCTLR_EL1[M] from a value of 1 to 0).
> 2) An exception level disabling its stage-1 translation if its stage-2
> translation is enabled (e.g. EL1 changing SCTLR_EL1[M] from a value of 1
> to 0 when HCR_EL2[VM] has a value of 1).
>
> To avoid the errant behavior, software must execute an ISB immediately
> prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.
>
> Signed-off-by: Shanker Donthineni
> ---
> Documentation/arm64/silicon-errata.txt | 1 +
> arch/arm64/Kconfig | 10 ++
> arch/arm64/include/asm/assembler.h | 18 ++
> arch/arm64/include/asm/cpucaps.h | 3 ++-
> arch/arm64/kernel/cpu-reset.S | 1 +
> arch/arm64/kernel/cpu_errata.c | 16
> arch/arm64/kernel/efi-entry.S | 2 ++
> arch/arm64/kernel/head.S | 1 +
> arch/arm64/kernel/relocate_kernel.S| 1 +
> arch/arm64/kvm/hyp-init.S | 1 +
> 10 files changed, 53 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/arm64/silicon-errata.txt
> b/Documentation/arm64/silicon-errata.txt
> index 66e8ce1..704770c0 100644
> --- a/Documentation/arm64/silicon-errata.txt
> +++ b/Documentation/arm64/silicon-errata.txt
> @@ -74,3 +74,4 @@ stable kernels.
> | Qualcomm Tech. | Falkor v1 | E1003 |
> QCOM_FALKOR_ERRATUM_1003|
> | Qualcomm Tech. | Falkor v1 | E1009 |
> QCOM_FALKOR_ERRATUM_1009|
> | Qualcomm Tech. | QDF2400 ITS | E0065 |
> QCOM_QDF2400_ERRATUM_0065 |
> +| Qualcomm Tech. | Falkor v{1,2} | E1041 |
> QCOM_FALKOR_ERRATUM_1041|
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 0df64a6..8f73eac 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -539,6 +539,16 @@ config QCOM_QDF2400_ERRATUM_0065
>
> If unsure, say Y.
>
> +config QCOM_FALKOR_ERRATUM_E1041
> + bool "Falkor E1041: Speculative instruction fetches might cause errant
> memory access"
> + default y
> + help
> + Falkor CPU may speculatively fetch instructions from an improper
> + memory location when MMU translation is changed from SCTLR_ELn[M]=1
> + to SCTLR_ELn[M]=0. Prefix an ISB instruction to fix the problem.
> +
> + If unsure, say Y.
> +
> endmenu
>
>
> diff --git a/arch/arm64/include/asm/assembler.h
> b/arch/arm64/include/asm/assembler.h
> index d58a625..eb11cdf 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -499,4 +499,22 @@
> #endif
> .endm
>
> +/**
> + * Errata workaround prior to disable MMU. Insert an ISB immediately prior
> + * to executing the MSR that will change SCTLR_ELn[M] from a value of 1 to 0.
> + */
> + .macro pre_disable_mmu_workaround
> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
> +alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1041
> + isb
> +alternative_else_nop_endif
> +#endif
> + .end
> +
> + .macro pre_disable_mmu_early_workaround
> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
> +
[PATCH v3 1/2] arm64: Define cputype macros for Falkor CPU
Add cputype definition macros for Qualcomm Datacenter Technologies Falkor CPU in cputype.h. It's unfortunate that the first revision of the Falkor CPU used the wrong part number 0x800, got fixed in v2 chip with part number 0xC00, and would be used the same value for future revisions. Signed-off-by: Shanker Donthineni --- arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h index 235e77d..cbf08d7 100644 --- a/arch/arm64/include/asm/cputype.h +++ b/arch/arm64/include/asm/cputype.h @@ -91,6 +91,7 @@ #define BRCM_CPU_PART_VULCAN 0x516 #define QCOM_CPU_PART_FALKOR_V10x800 +#define QCOM_CPU_PART_FALKOR 0xC00 #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53) #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57) @@ -99,6 +100,7 @@ #define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX) #define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX) #define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR_V1) +#define MIDR_QCOM_FALKOR MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR) #ifndef __ASSEMBLY__ -- Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] arm64: Add software workaround for Falkor erratum 1041
The ARM architecture defines the memory locations that are permitted
to be accessed as the result of a speculative instruction fetch from
an exception level for which all stages of translation are disabled.
Specifically, the core is permitted to speculatively fetch from the
4KB region containing the current program counter 4K and next 4K.
When translation is changed from enabled to disabled for the running
exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the
Falkor core may errantly speculatively access memory locations outside
of the 4KB region permitted by the architecture. The errant memory
access may lead to one of the following unexpected behaviors.
1) A System Error Interrupt (SEI) being raised by the Falkor core due
to the errant memory access attempting to access a region of memory
that is protected by a slave-side memory protection unit.
2) Unpredictable device behavior due to a speculative read from device
memory. This behavior may only occur if the instruction cache is
disabled prior to or coincident with translation being changed from
enabled to disabled.
The conditions leading to this erratum will not occur when either of the
following occur:
1) A higher exception level disables translation of a lower exception level
(e.g. EL2 changing SCTLR_EL1[M] from a value of 1 to 0).
2) An exception level disabling its stage-1 translation if its stage-2
translation is enabled (e.g. EL1 changing SCTLR_EL1[M] from a value of 1
to 0 when HCR_EL2[VM] has a value of 1).
To avoid the errant behavior, software must execute an ISB immediately
prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.
Signed-off-by: Shanker Donthineni
---
Changes since v1:
Apply the workaround where it's required.
Changes since v2:
Repost the corrected patches.
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 10 ++
arch/arm64/include/asm/assembler.h | 19 +++
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/kernel/cpu-reset.S | 1 +
arch/arm64/kernel/cpu_errata.c | 16
arch/arm64/kernel/efi-entry.S | 2 ++
arch/arm64/kernel/head.S | 1 +
arch/arm64/kernel/relocate_kernel.S| 1 +
arch/arm64/kvm/hyp-init.S | 1 +
10 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/Documentation/arm64/silicon-errata.txt
b/Documentation/arm64/silicon-errata.txt
index 66e8ce1..704770c0 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -74,3 +74,4 @@ stable kernels.
| Qualcomm Tech. | Falkor v1 | E1003 |
QCOM_FALKOR_ERRATUM_1003|
| Qualcomm Tech. | Falkor v1 | E1009 |
QCOM_FALKOR_ERRATUM_1009|
| Qualcomm Tech. | QDF2400 ITS | E0065 |
QCOM_QDF2400_ERRATUM_0065 |
+| Qualcomm Tech. | Falkor v{1,2} | E1041 |
QCOM_FALKOR_ERRATUM_1041|
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 0df64a6..8f73eac 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -539,6 +539,16 @@ config QCOM_QDF2400_ERRATUM_0065
If unsure, say Y.
+config QCOM_FALKOR_ERRATUM_E1041
+ bool "Falkor E1041: Speculative instruction fetches might cause errant
memory access"
+ default y
+ help
+ Falkor CPU may speculatively fetch instructions from an improper
+ memory location when MMU translation is changed from SCTLR_ELn[M]=1
+ to SCTLR_ELn[M]=0. Prefix an ISB instruction to fix the problem.
+
+ If unsure, say Y.
+
endmenu
diff --git a/arch/arm64/include/asm/assembler.h
b/arch/arm64/include/asm/assembler.h
index d58a625..dd9cec5 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
/*
* Enable and disable interrupts.
@@ -499,4 +500,22 @@
#endif
.endm
+/**
+ * Errata workaround prior to disable MMU. Insert an ISB immediately prior
+ * to executing the MSR that will change SCTLR_ELn[M] from a value of 1 to 0.
+ */
+ .macro pre_disable_mmu_workaround
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
+alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1041
+ isb
+alternative_else_nop_endif
+#endif
+ .endm
+
+ .macro pre_disable_mmu_early_workaround
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
+ isb
+#endif
+ .endm
+
#endif /* __ASM_ASSEMBLER_H */
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 8da6216..7f7a59d 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -40,7 +40,8 @@
#define ARM64_WORKAROUND_85892119
#define ARM64_WORKAROUND_CAVIUM_30115 20
#define ARM64_HAS_DCPOP21
+#define ARM64_WORKAROUND_QCOM_FALKOR_E1041 22
-#define ARM64_NCAPS
[PATCH v3 0/2] Implement a software workaround for Falkor erratum 1041
On Falkor CPU, we’ve discovered a hardware issue which might lead to a kernel crash or the unexpected behavior. The Falkor core may errantly access memory locations on speculative instruction fetches. This may happen whenever MMU translation state, SCTLR_ELn[M] bit is being changed from enabled to disabled for the currently running exception level. To prevent the errant hardware behavior, software must execute an ISB immediately prior to executing the MSR that changes SCTLR_ELn[M] from a value of 1 to 0. To simplify the complexity of a workaround, this patch series issues an ISB whenever SCTLR_ELn[M] is changed to 0 to fix the Falkor erratum 1041. Patch2 from V1 series got dropped to accommodate review comments. Apply the workaround where it's required. Posted wrong the patches in v2. Patch1: - CPUTYPE definitions for Falkor CPU. Patch2: - Actual workaround changes for erratum E1041. Shanker Donthineni (2): arm64: Define cputype macros for Falkor CPU arm64: Add software workaround for Falkor erratum 1041 Documentation/arm64/silicon-errata.txt | 1 + arch/arm64/Kconfig | 10 ++ arch/arm64/include/asm/assembler.h | 18 ++ arch/arm64/include/asm/cpucaps.h | 3 ++- arch/arm64/include/asm/cputype.h | 2 ++ arch/arm64/kernel/cpu-reset.S | 1 + arch/arm64/kernel/cpu_errata.c | 16 arch/arm64/kernel/efi-entry.S | 2 ++ arch/arm64/kernel/head.S | 1 + arch/arm64/kernel/relocate_kernel.S| 1 + arch/arm64/kvm/hyp-init.S | 1 + 11 files changed, 55 insertions(+), 1 deletion(-) -- Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] arm64: Define cputype macros for Falkor CPU
Add cputype definition macros for Qualcomm Datacenter Technologies Falkor CPU in cputype.h. It's unfortunate that the first revision of the Falkor CPU used the wrong part number 0x800, got fixed in v2 chip with part number 0xC00, and would be used the same value for future revisions. Signed-off-by: Shanker Donthineni --- arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h index 235e77d..cbf08d7 100644 --- a/arch/arm64/include/asm/cputype.h +++ b/arch/arm64/include/asm/cputype.h @@ -91,6 +91,7 @@ #define BRCM_CPU_PART_VULCAN 0x516 #define QCOM_CPU_PART_FALKOR_V10x800 +#define QCOM_CPU_PART_FALKOR 0xC00 #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53) #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57) @@ -99,6 +100,7 @@ #define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX) #define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX) #define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR_V1) +#define MIDR_QCOM_FALKOR MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR) #ifndef __ASSEMBLY__ -- Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] arm64: Add software workaround for Falkor erratum 1041
The ARM architecture defines the memory locations that are permitted
to be accessed as the result of a speculative instruction fetch from
an exception level for which all stages of translation are disabled.
Specifically, the core is permitted to speculatively fetch from the
4KB region containing the current program counter 4K and next 4K.
When translation is changed from enabled to disabled for the running
exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the
Falkor core may errantly speculatively access memory locations outside
of the 4KB region permitted by the architecture. The errant memory
access may lead to one of the following unexpected behaviors.
1) A System Error Interrupt (SEI) being raised by the Falkor core due
to the errant memory access attempting to access a region of memory
that is protected by a slave-side memory protection unit.
2) Unpredictable device behavior due to a speculative read from device
memory. This behavior may only occur if the instruction cache is
disabled prior to or coincident with translation being changed from
enabled to disabled.
The conditions leading to this erratum will not occur when either of the
following occur:
1) A higher exception level disables translation of a lower exception level
(e.g. EL2 changing SCTLR_EL1[M] from a value of 1 to 0).
2) An exception level disabling its stage-1 translation if its stage-2
translation is enabled (e.g. EL1 changing SCTLR_EL1[M] from a value of 1
to 0 when HCR_EL2[VM] has a value of 1).
To avoid the errant behavior, software must execute an ISB immediately
prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.
Signed-off-by: Shanker Donthineni
---
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 10 ++
arch/arm64/include/asm/assembler.h | 18 ++
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/kernel/cpu-reset.S | 1 +
arch/arm64/kernel/cpu_errata.c | 16
arch/arm64/kernel/efi-entry.S | 2 ++
arch/arm64/kernel/head.S | 1 +
arch/arm64/kernel/relocate_kernel.S| 1 +
arch/arm64/kvm/hyp-init.S | 1 +
10 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/Documentation/arm64/silicon-errata.txt
b/Documentation/arm64/silicon-errata.txt
index 66e8ce1..704770c0 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -74,3 +74,4 @@ stable kernels.
| Qualcomm Tech. | Falkor v1 | E1003 |
QCOM_FALKOR_ERRATUM_1003|
| Qualcomm Tech. | Falkor v1 | E1009 |
QCOM_FALKOR_ERRATUM_1009|
| Qualcomm Tech. | QDF2400 ITS | E0065 |
QCOM_QDF2400_ERRATUM_0065 |
+| Qualcomm Tech. | Falkor v{1,2} | E1041 |
QCOM_FALKOR_ERRATUM_1041|
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 0df64a6..8f73eac 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -539,6 +539,16 @@ config QCOM_QDF2400_ERRATUM_0065
If unsure, say Y.
+config QCOM_FALKOR_ERRATUM_E1041
+ bool "Falkor E1041: Speculative instruction fetches might cause errant
memory access"
+ default y
+ help
+ Falkor CPU may speculatively fetch instructions from an improper
+ memory location when MMU translation is changed from SCTLR_ELn[M]=1
+ to SCTLR_ELn[M]=0. Prefix an ISB instruction to fix the problem.
+
+ If unsure, say Y.
+
endmenu
diff --git a/arch/arm64/include/asm/assembler.h
b/arch/arm64/include/asm/assembler.h
index d58a625..eb11cdf 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -499,4 +499,22 @@
#endif
.endm
+/**
+ * Errata workaround prior to disable MMU. Insert an ISB immediately prior
+ * to executing the MSR that will change SCTLR_ELn[M] from a value of 1 to 0.
+ */
+ .macro pre_disable_mmu_workaround
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
+alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1041
+ isb
+alternative_else_nop_endif
+#endif
+ .end
+
+ .macro pre_disable_mmu_early_workaround
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
+ isb
+#endif
+ .end
+
#endif /* __ASM_ASSEMBLER_H */
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 8da6216..7f7a59d 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -40,7 +40,8 @@
#define ARM64_WORKAROUND_85892119
#define ARM64_WORKAROUND_CAVIUM_30115 20
#define ARM64_HAS_DCPOP21
+#define ARM64_WORKAROUND_QCOM_FALKOR_E1041 22
-#define ARM64_NCAPS22
+#define ARM64_NCAPS23
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/kernel/cpu-reset.S b/arch/arm64/kernel/cpu-reset.S
index 65f42d2..2a752cb 100644
--- a/arch/arm64/kernel/c
[PATCH v2 0/2] Implement a software workaround for Falkor erratum 1041
On Falkor CPU, we’ve discovered a hardware issue which might lead to a kernel crash or the unexpected behavior. The Falkor core may errantly access memory locations on speculative instruction fetches. This may happen whenever MMU translation state, SCTLR_ELn[M] bit is being changed from enabled to disabled for the currently running exception level. To prevent the errant hardware behavior, software must execute an ISB immediately prior to executing the MSR that changes SCTLR_ELn[M] from a value of 1 to 0. To simplify the complexity of a workaround, this patch series issues an ISB whenever SCTLR_ELn[M] is changed to 0 to fix the Falkor erratum 1041. Patch2 from V1 series got dropped to accommodate review comments. Apply the workaround where it's required. Patch1: - CPUTYPE definitions for Falkor CPU. Patch2: - Actual workaround changes for erratum E1041. Shanker Donthineni (2): arm64: Define cputype macros for Falkor CPU arm64: Add software workaround for Falkor erratum 1041 Documentation/arm64/silicon-errata.txt | 1 + arch/arm64/Kconfig | 10 ++ arch/arm64/include/asm/assembler.h | 18 ++ arch/arm64/include/asm/cpucaps.h | 3 ++- arch/arm64/include/asm/cputype.h | 2 ++ arch/arm64/kernel/cpu-reset.S | 1 + arch/arm64/kernel/cpu_errata.c | 16 arch/arm64/kernel/efi-entry.S | 2 ++ arch/arm64/kernel/head.S | 1 + arch/arm64/kernel/relocate_kernel.S| 1 + arch/arm64/kvm/hyp-init.S | 1 + 11 files changed, 55 insertions(+), 1 deletion(-) -- Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] arm64: Add software workaround for Falkor erratum 1041
Hi James,
On 11/10/2017 04:24 AM, James Morse wrote:
> Hi Shanker,
>
> On 09/11/17 15:22, Shanker Donthineni wrote:
>> On 11/09/2017 05:08 AM, James Morse wrote:
>>> On 04/11/17 21:43, Shanker Donthineni wrote:
>>>> On 11/03/2017 10:11 AM, Robin Murphy wrote:
>>>>> On 03/11/17 03:27, Shanker Donthineni wrote:
>>>>>> The ARM architecture defines the memory locations that are permitted
>>>>>> to be accessed as the result of a speculative instruction fetch from
>>>>>> an exception level for which all stages of translation are disabled.
>>>>>> Specifically, the core is permitted to speculatively fetch from the
>>>>>> 4KB region containing the current program counter and next 4KB.
>>>>>>
>>>>>> When translation is changed from enabled to disabled for the running
>>>>>> exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the
>>>>>> Falkor core may errantly speculatively access memory locations outside
>>>>>> of the 4KB region permitted by the architecture. The errant memory
>>>>>> access may lead to one of the following unexpected behaviors.
>>>>>>
>>>>>> 1) A System Error Interrupt (SEI) being raised by the Falkor core due
>>>>>>to the errant memory access attempting to access a region of memory
>>>>>>that is protected by a slave-side memory protection unit.
>>>>>> 2) Unpredictable device behavior due to a speculative read from device
>>>>>>memory. This behavior may only occur if the instruction cache is
>>>>>>disabled prior to or coincident with translation being changed from
>>>>>>enabled to disabled.
>>>>>>
>>>>>> To avoid the errant behavior, software must execute an ISB immediately
>>>>>> prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.
>
>>>>>> diff --git a/arch/arm64/include/asm/assembler.h
>>>>>> b/arch/arm64/include/asm/assembler.h
>>>>>> index b6dfb4f..4c91efb 100644
>>>>>> --- a/arch/arm64/include/asm/assembler.h
>>>>>> +++ b/arch/arm64/include/asm/assembler.h
>>>>>> @@ -514,6 +515,22 @@
>>>>>> * reg: the value to be written.
>>>>>> */
>>>>>> .macro write_sctlr, eln, reg
>>>>>> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1041
>>>>>> +alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1041
>>>>>> +tbnz\reg, #0, 8000f // enable MMU?
>>>
>>> Won't this match any change that leaves the MMU enabled?
>>
>> Yes. No need to apply workaround if the MMU is going to be enabled.
>
> (Sorry, looks like I had this upside down)
>
> My badly-made-point is you can't know if the MMU is being disabled unless you
> have both the old and new values.
>
> As an example, in el2_setup, (where the MMU is disabled), we set the EE/E0E
> bits
> to match the kernel's endianness. Won't your macro will insert an unnecessary
> isb? Is this needed for the errata workaround?
>
Yes, It's not required in this case. I'll post a v2 patch and apply the
workaround
where it's absolutely required. Seems handling a workaround inside helper macros
causing confusion.
>
>>> I think the macro is making this more confusing. Disabling the MMU is
>>> obvious
>>> from the call-site, (and really rare!). Trying to work it out from a macro
>>> makes
>>> it more complicated than necessary.
>
>> Not clear, are you suggesting not to use read{write}_sctlr() macros instead
>> apply
>> the workaround from the call-site based on the MMU-on status?
>
> Yes. This is the only way to patch only the locations that turn the MMU off.
>
>
>> If yes, It simplifies
>> the code logic but CONFIG_QCOM_FALKOR_ERRATUM_1041 references are scatter
>> everywhere.
>
> Wouldn't they only appear in the places that are affected by the errata?
> This is exactly what we want, anyone touching that code now knows they need to
> double check this behaviour, (and ask you to test it!).
>
> Otherwise we have a macro second guessing what is happening, if its not quite
> right (because some information has been lost), we're now not sure what we
> need
> to do if we ever refactor any of this code.
>
> [...]
>
>>>> I'll prefer alternatives
>>>> just to avoid the unnecessar
Re: [PATCH 3/3] arm64: Add software workaround for Falkor erratum 1041
Hi James,
On 11/09/2017 05:08 AM, James Morse wrote:
> Hi Shanker, Robin,
>
> On 04/11/17 21:43, Shanker Donthineni wrote:
>> On 11/03/2017 10:11 AM, Robin Murphy wrote:
>>> On 03/11/17 03:27, Shanker Donthineni wrote:
>>>> The ARM architecture defines the memory locations that are permitted
>>>> to be accessed as the result of a speculative instruction fetch from
>>>> an exception level for which all stages of translation are disabled.
>>>> Specifically, the core is permitted to speculatively fetch from the
>>>> 4KB region containing the current program counter and next 4KB.
>>>>
>>>> When translation is changed from enabled to disabled for the running
>>>> exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the
>>>> Falkor core may errantly speculatively access memory locations outside
>>>> of the 4KB region permitted by the architecture. The errant memory
>>>> access may lead to one of the following unexpected behaviors.
>>>>
>>>> 1) A System Error Interrupt (SEI) being raised by the Falkor core due
>>>>to the errant memory access attempting to access a region of memory
>>>>that is protected by a slave-side memory protection unit.
>>>> 2) Unpredictable device behavior due to a speculative read from device
>>>>memory. This behavior may only occur if the instruction cache is
>>>>disabled prior to or coincident with translation being changed from
>>>>enabled to disabled.
>>>>
>>>> To avoid the errant behavior, software must execute an ISB immediately
>>>> prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.
>
>
>>>> diff --git a/arch/arm64/include/asm/assembler.h
>>>> b/arch/arm64/include/asm/assembler.h
>>>> index b6dfb4f..4c91efb 100644
>>>> --- a/arch/arm64/include/asm/assembler.h
>>>> +++ b/arch/arm64/include/asm/assembler.h
>>>> @@ -30,6 +30,7 @@
>>>> #include
>>>> #include
>>>> #include
>>>> +#include
>>>>
>>>> /*
>>>> * Enable and disable interrupts.
>>>> @@ -514,6 +515,22 @@
>>>> * reg: the value to be written.
>>>> */
>>>>.macro write_sctlr, eln, reg
>>>> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1041
>>>> +alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1041
>>>> + tbnz\reg, #0, 8000f // enable MMU?
>
> Won't this match any change that leaves the MMU enabled?
>
Yes. No need to apply workaround if the MMU is going to be enabled.
> I think the macro is making this more confusing. Disabling the MMU is obvious
> from the call-site, (and really rare!). Trying to work it out from a macro
> makes
> it more complicated than necessary.
>
Not clear, are you suggesting not to use read{write}_sctlr() macros instead
apply
the workaround from the call-site based on the MMU-on status? If yes, It
simplifies
the code logic but CONFIG_QCOM_FALKOR_ERRATUM_1041 references are scatter
everywhere.
>
>>> Do we really need the branch here? It's not like enabling the MMU is
>>> something we do on the syscall fastpath, and I can't imagine an extra
>>> ISB hurts much (and is probably comparable to a mispredicted branch
>
>> I don't have any strong opinion on whether to use an ISB conditionally
>> or unconditionally. Yes, the current kernel code is not touching
>> SCTLR_ELn register on the system call fast path. I would like to keep
>> it as a conditional ISB in case if the future kernel accesses the
>> SCTLR_ELn on the fast path. An extra ISB should not hurt a lot but I
>> believe it has more overhead than the TBZ+branch mis-prediction on Falkor
>> CPU. This patch has been tested on the real hardware to fix the problem.
>
>> I'm open to change to an unconditional ISB if it's the better fix.
>>
>>> anyway). In fact, is there any noticeable hit on other
>>> microarchitectures if we save the alternative bother and just do it
>>> unconditionally always?
>>>
>>
>> I can't comment on the performance impacts of other CPUs since I don't
>> have access to their development platforms. I'll prefer alternatives
>> just to avoid the unnecessary overhead on future Qualcomm Datacenter
>> server CPUs and regression on other CPUs because of inserting an ISB
>
> I think hiding errata on other CPUs is a good argument.
>
> My suggestion would be:
>> #ifdef CONFIG_QCOM_FALK
Re: [PATCH 3/3] arm64: Add software workaround for Falkor erratum 1041
Hi Robin, Thanks for your review comments.
On 11/03/2017 10:11 AM, Robin Murphy wrote:
> On 03/11/17 03:27, Shanker Donthineni wrote:
>> The ARM architecture defines the memory locations that are permitted
>> to be accessed as the result of a speculative instruction fetch from
>> an exception level for which all stages of translation are disabled.
>> Specifically, the core is permitted to speculatively fetch from the
>> 4KB region containing the current program counter and next 4KB.
>>
>> When translation is changed from enabled to disabled for the running
>> exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the
>> Falkor core may errantly speculatively access memory locations outside
>> of the 4KB region permitted by the architecture. The errant memory
>> access may lead to one of the following unexpected behaviors.
>>
>> 1) A System Error Interrupt (SEI) being raised by the Falkor core due
>>to the errant memory access attempting to access a region of memory
>>that is protected by a slave-side memory protection unit.
>> 2) Unpredictable device behavior due to a speculative read from device
>>memory. This behavior may only occur if the instruction cache is
>>disabled prior to or coincident with translation being changed from
>>enabled to disabled.
>>
>> To avoid the errant behavior, software must execute an ISB immediately
>> prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.
>>
>> Signed-off-by: Shanker Donthineni
>> ---
>> Documentation/arm64/silicon-errata.txt | 1 +
>> arch/arm64/Kconfig | 10 ++
>> arch/arm64/include/asm/assembler.h | 17 +
>> arch/arm64/include/asm/cpucaps.h | 3 ++-
>> arch/arm64/kernel/cpu_errata.c | 16
>> arch/arm64/kernel/efi-entry.S | 4 ++--
>> arch/arm64/kernel/head.S | 4 ++--
>> 7 files changed, 50 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/arm64/silicon-errata.txt
>> b/Documentation/arm64/silicon-errata.txt
>> index 66e8ce1..704770c0 100644
>> --- a/Documentation/arm64/silicon-errata.txt
>> +++ b/Documentation/arm64/silicon-errata.txt
>> @@ -74,3 +74,4 @@ stable kernels.
>> | Qualcomm Tech. | Falkor v1 | E1003 |
>> QCOM_FALKOR_ERRATUM_1003|
>> | Qualcomm Tech. | Falkor v1 | E1009 |
>> QCOM_FALKOR_ERRATUM_1009|
>> | Qualcomm Tech. | QDF2400 ITS | E0065 |
>> QCOM_QDF2400_ERRATUM_0065 |
>> +| Qualcomm Tech. | Falkor v{1,2} | E1041 |
>> QCOM_FALKOR_ERRATUM_1041|
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 0df64a6..7e933fb 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -539,6 +539,16 @@ config QCOM_QDF2400_ERRATUM_0065
>>
>>If unsure, say Y.
>>
>> +config QCOM_FALKOR_ERRATUM_1041
>> +bool "Falkor E1041: Speculative instruction fetches might cause errant
>> memory access"
>> +default y
>> +help
>> + Falkor CPU may speculatively fetch instructions from an improper
>> + memory location when MMU translation is changed from SCTLR_ELn[M]=1
>> + to SCTLR_ELn[M]=0. Prefix an ISB instruction to fix the problem.
>> +
>> + If unsure, say Y.
>> +
>> endmenu
>>
>>
>> diff --git a/arch/arm64/include/asm/assembler.h
>> b/arch/arm64/include/asm/assembler.h
>> index b6dfb4f..4c91efb 100644
>> --- a/arch/arm64/include/asm/assembler.h
>> +++ b/arch/arm64/include/asm/assembler.h
>> @@ -30,6 +30,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> /*
>> * Enable and disable interrupts.
>> @@ -514,6 +515,22 @@
>> * reg: the value to be written.
>> */
>> .macro write_sctlr, eln, reg
>> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1041
>> +alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1041
>> +tbnz\reg, #0, 8000f // enable MMU?
>
> Do we really need the branch here? It's not like enabling the MMU is
> something we do on the syscall fastpath, and I can't imagine an extra
> ISB hurts much (and is probably comparable to a mispredicted branch
I don't have any strong opinion on whether to use an ISB conditionally
or unconditionally. Yes, the current kernel code is not touching
SCTLR_ELn register on the system call fast path. I would like to keep
it as a conditional ISB in case if the future kernel accesses the
SCTLR_ELn on the fast path. An
[PATCH 1/3] arm64: Define cputype macros for Falkor CPU
Add cputype definition macros for Qualcomm Datacenter Technologies Falkor CPU in cputype.h. It's unfortunate that the first revision of the Falkor CPU used the wrong part number 0x800, got fixed in v2 chip with part number 0xC00, and would be used the same value for future revisions. Signed-off-by: Shanker Donthineni Signed-off-by: Neil Leeder --- arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h index 235e77d..cbf08d7 100644 --- a/arch/arm64/include/asm/cputype.h +++ b/arch/arm64/include/asm/cputype.h @@ -91,6 +91,7 @@ #define BRCM_CPU_PART_VULCAN 0x516 #define QCOM_CPU_PART_FALKOR_V10x800 +#define QCOM_CPU_PART_FALKOR 0xC00 #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53) #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57) @@ -99,6 +100,7 @@ #define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX) #define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX) #define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR_V1) +#define MIDR_QCOM_FALKOR MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR) #ifndef __ASSEMBLY__ -- Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] arm64: Prepare SCTLR_ELn accesses to handle Falkor erratum 1041
This patch introduces two helper macros read_sctlr and write_sctlr
to access system register SCTLR_ELn. Replace all MSR/MRS references
to sctlr_el1{el2} with macros.
This should cause no behavioral change.
Signed-off-by: Shanker Donthineni
---
arch/arm64/include/asm/assembler.h | 18 ++
arch/arm64/kernel/cpu-reset.S | 4 ++--
arch/arm64/kernel/efi-entry.S | 8
arch/arm64/kernel/head.S| 18 +-
arch/arm64/kernel/relocate_kernel.S | 4 ++--
arch/arm64/kvm/hyp-init.S | 6 +++---
arch/arm64/mm/proc.S| 6 +++---
7 files changed, 41 insertions(+), 23 deletions(-)
diff --git a/arch/arm64/include/asm/assembler.h
b/arch/arm64/include/asm/assembler.h
index d58a625..b6dfb4f 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -499,4 +499,22 @@
#endif
.endm
+/**
+ * Read value of the system control register SCTLR_ELn.
+ * eln: which system control register.
+ * reg: contents of the SCTLR_ELn.
+ */
+ .macro read_sctlr, eln, reg
+ mrs \reg, sctlr_\eln
+ .endm
+
+/**
+ * Write the value to the system control register SCTLR_ELn.
+ * eln: which system control register.
+ * reg: the value to be written.
+ */
+ .macro write_sctlr, eln, reg
+ msr sctlr_\eln, \reg
+ .endm
+
#endif /* __ASM_ASSEMBLER_H */
diff --git a/arch/arm64/kernel/cpu-reset.S b/arch/arm64/kernel/cpu-reset.S
index 65f42d2..9224abd 100644
--- a/arch/arm64/kernel/cpu-reset.S
+++ b/arch/arm64/kernel/cpu-reset.S
@@ -34,10 +34,10 @@
*/
ENTRY(__cpu_soft_restart)
/* Clear sctlr_el1 flags. */
- mrs x12, sctlr_el1
+ read_sctlr el1, x12
ldr x13, =SCTLR_ELx_FLAGS
bic x12, x12, x13
- msr sctlr_el1, x12
+ write_sctlr el1, x12
isb
cbz x0, 1f // el2_switch?
diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S
index 4e6ad35..acae627 100644
--- a/arch/arm64/kernel/efi-entry.S
+++ b/arch/arm64/kernel/efi-entry.S
@@ -93,17 +93,17 @@ ENTRY(entry)
mrs x0, CurrentEL
cmp x0, #CurrentEL_EL2
b.ne1f
- mrs x0, sctlr_el2
+ read_sctlr el2, x0
bic x0, x0, #1 << 0 // clear SCTLR.M
bic x0, x0, #1 << 2 // clear SCTLR.C
- msr sctlr_el2, x0
+ write_sctlr el2, x0
isb
b 2f
1:
- mrs x0, sctlr_el1
+ read_sctlr el1, x0
bic x0, x0, #1 << 0 // clear SCTLR.M
bic x0, x0, #1 << 2 // clear SCTLR.C
- msr sctlr_el1, x0
+ write_sctlr el1, x0
isb
2:
/* Jump to kernel entry point */
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 0b243ec..b8d5b73 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -388,18 +388,18 @@ ENTRY(el2_setup)
mrs x0, CurrentEL
cmp x0, #CurrentEL_EL2
b.eq1f
- mrs x0, sctlr_el1
+ read_sctlr el1, x0
CPU_BE(orr x0, x0, #(3 << 24) ) // Set the EE and E0E
bits for EL1
CPU_LE(bic x0, x0, #(3 << 24) ) // Clear the EE and E0E
bits for EL1
- msr sctlr_el1, x0
+ write_sctlr el1, x0
mov w0, #BOOT_CPU_MODE_EL1 // This cpu booted in EL1
isb
ret
-1: mrs x0, sctlr_el2
+1: read_sctlr el2, x0
CPU_BE(orr x0, x0, #(1 << 25) ) // Set the EE bit for
EL2
CPU_LE(bic x0, x0, #(1 << 25) ) // Clear the EE bit for
EL2
- msr sctlr_el2, x0
+ write_sctlr el2, x0
#ifdef CONFIG_ARM64_VHE
/*
@@ -511,7 +511,7 @@ install_el2_stub:
mov x0, #0x0800 // Set/clear RES{1,0} bits
CPU_BE(movkx0, #0x33d0, lsl #16) // Set EE and E0E on BE
systems
CPU_LE(movkx0, #0x30d0, lsl #16) // Clear EE and E0E on
LE systems
- msr sctlr_el1, x0
+ write_sctlr el1, x0
/* Coprocessor traps. */
mov x0, #0x33ff
@@ -664,7 +664,7 @@ ENTRY(__enable_mmu)
msr ttbr0_el1, x1 // load TTBR0
msr ttbr1_el1, x2 // load TTBR1
isb
- msr sctlr_el1, x0
+ write_sctlr el1, x0
isb
/*
* Invalidate the local I-cache so that any instructions fetched
@@ -716,7 +716,7 @@ ENDPROC(__relocate_kernel)
__primary_switch:
#ifdef CONFIG_RANDOMIZE_BASE
mov x19, x0 // preserve new SCTLR_EL1 value
- mrs x20, sctlr_el1 // preserve old SCTLR_EL1 value
+ read_sctlr el1, x20 // preserve old SCTLR_EL1 value
#endif
bl __enable_mmu
@@ -732,14 +732,14 @@ __primary_switch:
* to take into acco
[PATCH 3/3] arm64: Add software workaround for Falkor erratum 1041
The ARM architecture defines the memory locations that are permitted
to be accessed as the result of a speculative instruction fetch from
an exception level for which all stages of translation are disabled.
Specifically, the core is permitted to speculatively fetch from the
4KB region containing the current program counter and next 4KB.
When translation is changed from enabled to disabled for the running
exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the
Falkor core may errantly speculatively access memory locations outside
of the 4KB region permitted by the architecture. The errant memory
access may lead to one of the following unexpected behaviors.
1) A System Error Interrupt (SEI) being raised by the Falkor core due
to the errant memory access attempting to access a region of memory
that is protected by a slave-side memory protection unit.
2) Unpredictable device behavior due to a speculative read from device
memory. This behavior may only occur if the instruction cache is
disabled prior to or coincident with translation being changed from
enabled to disabled.
To avoid the errant behavior, software must execute an ISB immediately
prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.
Signed-off-by: Shanker Donthineni
---
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 10 ++
arch/arm64/include/asm/assembler.h | 17 +
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/kernel/cpu_errata.c | 16
arch/arm64/kernel/efi-entry.S | 4 ++--
arch/arm64/kernel/head.S | 4 ++--
7 files changed, 50 insertions(+), 5 deletions(-)
diff --git a/Documentation/arm64/silicon-errata.txt
b/Documentation/arm64/silicon-errata.txt
index 66e8ce1..704770c0 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -74,3 +74,4 @@ stable kernels.
| Qualcomm Tech. | Falkor v1 | E1003 |
QCOM_FALKOR_ERRATUM_1003|
| Qualcomm Tech. | Falkor v1 | E1009 |
QCOM_FALKOR_ERRATUM_1009|
| Qualcomm Tech. | QDF2400 ITS | E0065 |
QCOM_QDF2400_ERRATUM_0065 |
+| Qualcomm Tech. | Falkor v{1,2} | E1041 |
QCOM_FALKOR_ERRATUM_1041|
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 0df64a6..7e933fb 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -539,6 +539,16 @@ config QCOM_QDF2400_ERRATUM_0065
If unsure, say Y.
+config QCOM_FALKOR_ERRATUM_1041
+ bool "Falkor E1041: Speculative instruction fetches might cause errant
memory access"
+ default y
+ help
+ Falkor CPU may speculatively fetch instructions from an improper
+ memory location when MMU translation is changed from SCTLR_ELn[M]=1
+ to SCTLR_ELn[M]=0. Prefix an ISB instruction to fix the problem.
+
+ If unsure, say Y.
+
endmenu
diff --git a/arch/arm64/include/asm/assembler.h
b/arch/arm64/include/asm/assembler.h
index b6dfb4f..4c91efb 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
/*
* Enable and disable interrupts.
@@ -514,6 +515,22 @@
* reg: the value to be written.
*/
.macro write_sctlr, eln, reg
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1041
+alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1041
+ tbnz\reg, #0, 8000f // enable MMU?
+ isb
+8000:
+alternative_else_nop_endif
+#endif
+ msr sctlr_\eln, \reg
+ .endm
+
+ .macro early_write_sctlr, eln, reg
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1041
+ tbnz\reg, #0, 8000f // enable MMU?
+ isb
+8000:
+#endif
msr sctlr_\eln, \reg
.endm
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 8da6216..7f7a59d 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -40,7 +40,8 @@
#define ARM64_WORKAROUND_85892119
#define ARM64_WORKAROUND_CAVIUM_30115 20
#define ARM64_HAS_DCPOP21
+#define ARM64_WORKAROUND_QCOM_FALKOR_E1041 22
-#define ARM64_NCAPS22
+#define ARM64_NCAPS23
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 0e27f86..27f9a45 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -179,6 +179,22 @@ static int cpu_enable_trap_ctr_access(void *__unused)
MIDR_CPU_VAR_REV(0, 0)),
},
#endif
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1041
+ {
+ .desc = "Qualcomm Technologies Falkor erratum 1041",
+ .capability = ARM64_WORKAROUND_QCOM_FALKOR_E1041,
+ MIDR_RANGE
[PATCH 0/3] Implement a software workaround for Falkor erratum 1041
On Falkor CPU, we’ve discovered a hardware issue which might lead to a kernel crash or the unexpected behavior. The Falkor core may errantly access memory locations on speculative instruction fetches. This may happen whenever MMU translation state, SCTLR_ELn[M] bit is being changed from enabled to disabled for the currently running exception level. To prevent the errant hardware behavior, software must execute an ISB immediately prior to executing the MSR that changes SCTLR_ELn[M] from a value of 1 to 0. To simplify the complexity of a workaround, this patch series issues an ISB whenever SCTLR_ELn[M] is changed to 0 to fix the Falkor erratum 1041. Patch1: - CPUTYPE definitions for Falkor CPU. Patch2: - Define two ASM helper macros to read/write SCTLR_ELn register. Patch3: - Actual workaround changes for erratum E1041. Shanker Donthineni (3): arm64: Define cputype macros for Falkor CPU arm64: Prepare SCTLR_ELn accesses to handle Falkor erratum 1041 arm64: Add software workaround for Falkor erratum 1041 Documentation/arm64/silicon-errata.txt | 1 + arch/arm64/Kconfig | 10 ++ arch/arm64/include/asm/assembler.h | 35 ++ arch/arm64/include/asm/cpucaps.h | 3 ++- arch/arm64/include/asm/cputype.h | 2 ++ arch/arm64/kernel/cpu-reset.S | 4 ++-- arch/arm64/kernel/cpu_errata.c | 16 arch/arm64/kernel/efi-entry.S | 8 arch/arm64/kernel/head.S | 18 - arch/arm64/kernel/relocate_kernel.S| 4 ++-- arch/arm64/kvm/hyp-init.S | 6 +++--- arch/arm64/mm/proc.S | 6 +++--- 12 files changed, 89 insertions(+), 24 deletions(-) -- Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
