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

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

[Suzuki K Poulose]

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.

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.

Suzuki

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

[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