On 2018-01-17 02:28, Suzuki K Poulose wrote:
On 17/01/18 03:34, ckad...@codeaurora.org wrote:
On 2018-01-16 02:23, Suzuki K Poulose wrote:
Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer
from an erratum 1024718, which causes incorrect updates when DBM/AP
bits in a page table entry is modified without a break-before-make
sequence. The work around is to disable the hardware DBM feature
on the affected cores. The hardware Access Flag management features
is not affected.
The hardware DBM feature is a non-conflicting capability, i.e, the
kernel could handle cores using the feature and those without having
the features running at the same time. So this work around is
detected
at early boot time, rather than delaying it until the CPUs are
brought
up into the kernel with MMU turned on. This also avoids other
complexities
with late CPUs turning online, with or without the hardware DBM
features.
Cc: Catalin Marinas <catalin.mari...@arm.com>
Cc: Mark Rutland <mark.rutl...@arm.com>
Cc: Will Deacon <will.dea...@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poul...@arm.com>
---
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 14 ++++++++++++++
arch/arm64/mm/proc.S | 5 +++++
3 files changed, 20 insertions(+)
diff --git a/Documentation/arm64/silicon-errata.txt
b/Documentation/arm64/silicon-errata.txt
index b9d93e981a05..5203e71c113d 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -55,6 +55,7 @@ stable kernels.
| ARM | Cortex-A57 | #834220 |
ARM64_ERRATUM_834220 |
| ARM | Cortex-A72 | #853709 | N/A
|
| ARM | Cortex-A73 | #858921 |
ARM64_ERRATUM_858921 |
+| ARM | Cortex-A55 | #1024718 |
ARM64_ERRATUM_1024718 |
| ARM | MMU-500 | #841119,#826419 | N/A
|
| | | |
|
| Cavium | ThunderX ITS | #22375, #24313 |
CAVIUM_ERRATUM_22375 |
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 664fadc2aa2e..19b8407a0325 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -461,6 +461,20 @@ config ARM64_ERRATUM_843419
If unsure, say Y.
+config ARM64_ERRATUM_1024718
+ bool "Cortex-A55: 1024718: Update of DBM/AP bits without break
before make might result in incorrect update"
+ default y
+ help
+ This option adds work around for Arm Cortex-A55 Erratum
1024718.
+
+ Affected Cortex-A55 cores (r0p0, r0p1, r1p0) could cause
incorrect
+ update of the hardware dirty bit when the DBM/AP bits are
updated
+ without a break-before-make. The work around is to disable the
usage
+ of hardware DBM locally on the affected cores. CPUs not
affected by
+ erratum will continue to use the feature.
+
+ If unsure, say Y.
+
config CAVIUM_ERRATUM_22375
bool "Cavium erratum 22375, 24313"
default y
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 5a59eea49395..ba2c22180f4e 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -252,6 +252,11 @@ ENTRY(__cpu_setup)
cbz x9, 2f
cmp x9, #2
b.lt 1f
+#ifdef CONFIG_ARM64_ERRATUM_1024718
+ /* Disable hardware DBM on Cortex-A55 r0p0, r0p1 & r1p0 */
+ cpu_midr_match MIDR_CORTEX_A55, MIDR_CPU_VAR_REV(0, 0),
What is there is a custom core with different MIDRs, can we specify
multiple MIDR values?
At the moment no. May be we could pass a table of such values to the
macro ?
Would it be good to clear the bit as part of
arch/arm64/kernel/cpu_errata.c so we can specify multiple MIDR values
if required.
The problem is, we already have some part of the kernel mappings with
PTE_DBM set
(PTE_WRITE = PTE_DBM with CONFIG_HW_AFDBM) and could potentially hit
the errata,
before we disable it on the CPU. Also, if the CPU is brought up late
by userspace,
that adds more entities. I had another approach, where we delay
enabling the
TCR_HD until all cores are up. But then it has other complexities with
the CPU
feature framework.
e.g, we can't use the feature unless we turn the HADBS feature bit to
HIGHER_SAFE
so that we can turn it on if at least one CPU has it. But then, we
don't know
what the future values of the feature could imply, leaving that choice
unsafe.
Also, a late CPU will be prevented from booting if it doesn't have DBM
unless
we hack the framework.
I was thinking if we can enable the DBM feature based on a cpu feature
register.
Not sure if all future CPUs would have a bit for identifying whether DBM
is supported
or not.
So an early check seemed the easier solution at the moment. I will take
a look
at changing the framework a little bit and see where it takes us.
Otherwise,
we could switch back to a table of affected MIDRs.
Agree, its better to change the implementation to take a table of MIDRs.
Suzuki
--
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
a Linux Foundation Collaborative Project