[PATCH 3/3] arm64: Add work around for Arm Cortex-A55 Erratum 1024718

[ckadabi@codeaurora.org (Channa)]

On 2018-01-17 02:28, Suzuki K Poulose wrote:
> On 17/01/18 03:34, ckadabi at 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.marinas@arm.com>
>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>> Cc: Will Deacon <will.deacon@arm.com>
>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@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