mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-24 19:40:12 +07:00
932b50c7c1
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 <shankerd@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
79 lines
4.9 KiB
Plaintext
79 lines
4.9 KiB
Plaintext
Silicon Errata and Software Workarounds
|
|
=======================================
|
|
|
|
Author: Will Deacon <will.deacon@arm.com>
|
|
Date : 27 November 2015
|
|
|
|
It is an unfortunate fact of life that hardware is often produced with
|
|
so-called "errata", which can cause it to deviate from the architecture
|
|
under specific circumstances. For hardware produced by ARM, these
|
|
errata are broadly classified into the following categories:
|
|
|
|
Category A: A critical error without a viable workaround.
|
|
Category B: A significant or critical error with an acceptable
|
|
workaround.
|
|
Category C: A minor error that is not expected to occur under normal
|
|
operation.
|
|
|
|
For more information, consult one of the "Software Developers Errata
|
|
Notice" documents available on infocenter.arm.com (registration
|
|
required).
|
|
|
|
As far as Linux is concerned, Category B errata may require some special
|
|
treatment in the operating system. For example, avoiding a particular
|
|
sequence of code, or configuring the processor in a particular way. A
|
|
less common situation may require similar actions in order to declassify
|
|
a Category A erratum into a Category C erratum. These are collectively
|
|
known as "software workarounds" and are only required in the minority of
|
|
cases (e.g. those cases that both require a non-secure workaround *and*
|
|
can be triggered by Linux).
|
|
|
|
For software workarounds that may adversely impact systems unaffected by
|
|
the erratum in question, a Kconfig entry is added under "Kernel
|
|
Features" -> "ARM errata workarounds via the alternatives framework".
|
|
These are enabled by default and patched in at runtime when an affected
|
|
CPU is detected. For less-intrusive workarounds, a Kconfig option is not
|
|
available and the code is structured (preferably with a comment) in such
|
|
a way that the erratum will not be hit.
|
|
|
|
This approach can make it slightly onerous to determine exactly which
|
|
errata are worked around in an arbitrary kernel source tree, so this
|
|
file acts as a registry of software workarounds in the Linux Kernel and
|
|
will be updated when new workarounds are committed and backported to
|
|
stable kernels.
|
|
|
|
| Implementor | Component | Erratum ID | Kconfig |
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
|
| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
|
|
| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
|
|
| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
|
|
| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 |
|
|
| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 |
|
|
| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 |
|
|
| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
|
|
| ARM | Cortex-A57 | #852523 | N/A |
|
|
| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
|
|
| ARM | Cortex-A72 | #853709 | N/A |
|
|
| ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 |
|
|
| ARM | MMU-500 | #841119,#826419 | N/A |
|
|
| | | | |
|
|
| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |
|
|
| Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 |
|
|
| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
|
|
| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
|
|
| Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115 |
|
|
| Cavium | ThunderX SMMUv2 | #27704 | N/A |
|
|
| Cavium | ThunderX2 SMMUv3| #74 | N/A |
|
|
| Cavium | ThunderX2 SMMUv3| #126 | N/A |
|
|
| | | | |
|
|
| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
|
|
| | | | |
|
|
| Hisilicon | Hip0{5,6,7} | #161010101 | HISILICON_ERRATUM_161010101 |
|
|
| Hisilicon | Hip0{6,7} | #161010701 | N/A |
|
|
| Hisilicon | Hip07 | #161600802 | HISILICON_ERRATUM_161600802 |
|
|
| | | | |
|
|
| 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 |
|