2019-06-13 01:52:38 +08:00
|
|
|
=======================================
|
|
|
|
Silicon Errata and Software Workarounds
|
|
|
|
=======================================
|
2015-11-17 22:45:47 +08:00
|
|
|
|
|
|
|
Author: Will Deacon <will.deacon@arm.com>
|
2019-06-13 01:52:38 +08:00
|
|
|
|
2015-11-17 22:45:47 +08:00
|
|
|
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:
|
|
|
|
|
2019-06-13 01:52:38 +08:00
|
|
|
========== ========================================================
|
|
|
|
Category A A critical error without a viable workaround.
|
|
|
|
Category B A significant or critical error with an acceptable
|
2015-11-17 22:45:47 +08:00
|
|
|
workaround.
|
2019-06-13 01:52:38 +08:00
|
|
|
Category C A minor error that is not expected to occur under normal
|
2015-11-17 22:45:47 +08:00
|
|
|
operation.
|
2019-06-13 01:52:38 +08:00
|
|
|
========== ========================================================
|
2015-11-17 22:45:47 +08:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2017-02-10 01:00:34 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-06-13 01:52:38 +08:00
|
|
|
| Implementor | Component | Erratum ID | Kconfig |
|
|
|
|
+================+=================+=================+=============================+
|
clocksource/drivers/arch_timer: Workaround for Allwinner A64 timer instability
The Allwinner A64 SoC is known[1] to have an unstable architectural
timer, which manifests itself most obviously in the time jumping forward
a multiple of 95 years[2][3]. This coincides with 2^56 cycles at a
timer frequency of 24 MHz, implying that the time went slightly backward
(and this was interpreted by the kernel as it jumping forward and
wrapping around past the epoch).
Investigation revealed instability in the low bits of CNTVCT at the
point a high bit rolls over. This leads to power-of-two cycle forward
and backward jumps. (Testing shows that forward jumps are about twice as
likely as backward jumps.) Since the counter value returns to normal
after an indeterminate read, each "jump" really consists of both a
forward and backward jump from the software perspective.
Unless the kernel is trapping CNTVCT reads, a userspace program is able
to read the register in a loop faster than it changes. A test program
running on all 4 CPU cores that reported jumps larger than 100 ms was
run for 13.6 hours and reported the following:
Count | Event
-------+---------------------------
9940 | jumped backward 699ms
268 | jumped backward 1398ms
1 | jumped backward 2097ms
16020 | jumped forward 175ms
6443 | jumped forward 699ms
2976 | jumped forward 1398ms
9 | jumped forward 356516ms
9 | jumped forward 357215ms
4 | jumped forward 714430ms
1 | jumped forward 3578440ms
This works out to a jump larger than 100 ms about every 5.5 seconds on
each CPU core.
The largest jump (almost an hour!) was the following sequence of reads:
0x0000007fffffffff → 0x00000093feffffff → 0x0000008000000000
Note that the middle bits don't necessarily all read as all zeroes or
all ones during the anomalous behavior; however the low 10 bits checked
by the function in this patch have never been observed with any other
value.
Also note that smaller jumps are much more common, with backward jumps
of 2048 (2^11) cycles observed over 400 times per second on each core.
(Of course, this is partially explained by lower bits rolling over more
frequently.) Any one of these could have caused the 95 year time skip.
Similar anomalies were observed while reading CNTPCT (after patching the
kernel to allow reads from userspace). However, the CNTPCT jumps are
much less frequent, and only small jumps were observed. The same program
as before (except now reading CNTPCT) observed after 72 hours:
Count | Event
-------+---------------------------
17 | jumped backward 699ms
52 | jumped forward 175ms
2831 | jumped forward 699ms
5 | jumped forward 1398ms
Further investigation showed that the instability in CNTPCT/CNTVCT also
affected the respective timer's TVAL register. The following values were
observed immediately after writing CNVT_TVAL to 0x10000000:
CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error
--------------------+------------+--------------------+-----------------
0x000000d4a2d8bfff | 0x10003fff | 0x000000d4b2d8bfff | +0x00004000
0x000000d4a2d94000 | 0x0fffffff | 0x000000d4b2d97fff | -0x00004000
0x000000d4a2d97fff | 0x10003fff | 0x000000d4b2d97fff | +0x00004000
0x000000d4a2d9c000 | 0x0fffffff | 0x000000d4b2d9ffff | -0x00004000
The pattern of errors in CNTV_TVAL seemed to depend on exactly which
value was written to it. For example, after writing 0x10101010:
CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error
--------------------+------------+--------------------+-----------------
0x000001ac3effffff | 0x1110100f | 0x000001ac4f10100f | +0x1000000
0x000001ac40000000 | 0x1010100f | 0x000001ac5110100f | -0x1000000
0x000001ac58ffffff | 0x1110100f | 0x000001ac6910100f | +0x1000000
0x000001ac66000000 | 0x1010100f | 0x000001ac7710100f | -0x1000000
0x000001ac6affffff | 0x1110100f | 0x000001ac7b10100f | +0x1000000
0x000001ac6e000000 | 0x1010100f | 0x000001ac7f10100f | -0x1000000
I was also twice able to reproduce the issue covered by Allwinner's
workaround[4], that writing to TVAL sometimes fails, and both CVAL and
TVAL are left with entirely bogus values. One was the following values:
CNTVCT | CNTV_TVAL | CNTV_CVAL
--------------------+------------+--------------------------------------
0x000000d4a2d6014c | 0x8fbd5721 | 0x000000d132935fff (615s in the past)
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
========================================================================
Because the CPU can read the CNTPCT/CNTVCT registers faster than they
change, performing two reads of the register and comparing the high bits
(like other workarounds) is not a workable solution. And because the
timer can jump both forward and backward, no pair of reads can
distinguish a good value from a bad one. The only way to guarantee a
good value from consecutive reads would be to read _three_ times, and
take the middle value only if the three values are 1) each unique and
2) increasing. This takes at minimum 3 counter cycles (125 ns), or more
if an anomaly is detected.
However, since there is a distinct pattern to the bad values, we can
optimize the common case (1022/1024 of the time) to a single read by
simply ignoring values that match the error pattern. This still takes no
more than 3 cycles in the worst case, and requires much less code. As an
additional safety check, we still limit the loop iteration to the number
of max-frequency (1.2 GHz) CPU cycles in three 24 MHz counter periods.
For the TVAL registers, the simple solution is to not use them. Instead,
read or write the CVAL and calculate the TVAL value in software.
Although the manufacturer is aware of at least part of the erratum[4],
there is no official name for it. For now, use the kernel-internal name
"UNKNOWN1".
[1]: https://github.com/armbian/build/commit/a08cd6fe7ae9
[2]: https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/
[3]: https://irclog.whitequark.org/linux-sunxi/2018-01-26
[4]: https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/master/drivers/clocksource/arm_arch_timer.c#L272
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2019-01-13 10:17:18 +08:00
|
|
|
| Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-02-10 01:00:34 +08:00
|
|
|
| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-02-10 01:00:34 +08:00
|
|
|
| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-02-10 01:00:34 +08:00
|
|
|
| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-02-10 01:00:34 +08:00
|
|
|
| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-02-10 01:00:34 +08:00
|
|
|
| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-02-10 01:00:34 +08:00
|
|
|
| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2020-04-30 03:19:21 +08:00
|
|
|
| ARM | Cortex-A55 | #1024718 | ARM64_ERRATUM_1024718 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
|
|
|
| ARM | Cortex-A55 | #1530923 | ARM64_ERRATUM_1530923 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2022-09-30 21:19:59 +08:00
|
|
|
| ARM | Cortex-A55 | #2441007 | ARM64_ERRATUM_2441007 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-02-10 01:00:34 +08:00
|
|
|
| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-02-10 01:00:34 +08:00
|
|
|
| ARM | Cortex-A57 | #852523 | N/A |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-02-10 01:00:34 +08:00
|
|
|
| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-01-09 22:36:34 +08:00
|
|
|
| ARM | Cortex-A57 | #1319537 | ARM64_ERRATUM_1319367 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2022-07-15 00:15:23 +08:00
|
|
|
| ARM | Cortex-A57 | #1742098 | ARM64_ERRATUM_1742098 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-02-10 01:00:34 +08:00
|
|
|
| ARM | Cortex-A72 | #853709 | N/A |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-01-09 22:36:34 +08:00
|
|
|
| ARM | Cortex-A72 | #1319367 | ARM64_ERRATUM_1319367 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2022-07-15 00:15:23 +08:00
|
|
|
| ARM | Cortex-A72 | #1655431 | ARM64_ERRATUM_1742098 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-03-21 01:18:06 +08:00
|
|
|
| ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-05-23 18:24:50 +08:00
|
|
|
| ARM | Cortex-A76 | #1188873,1418040| ARM64_ERRATUM_1418040 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2018-12-07 01:31:26 +08:00
|
|
|
| ARM | Cortex-A76 | #1165522 | ARM64_ERRATUM_1165522 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2018-11-19 19:27:28 +08:00
|
|
|
| ARM | Cortex-A76 | #1286807 | ARM64_ERRATUM_1286807 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-04-29 20:03:57 +08:00
|
|
|
| ARM | Cortex-A76 | #1463225 | ARM64_ERRATUM_1463225 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
arm64: errata: Expand speculative SSBS workaround (again)
[ Upstream commit adeec61a4723fd3e39da68db4cc4d924e6d7f641 ]
A number of Arm Ltd CPUs suffer from errata whereby an MSR to the SSBS
special-purpose register does not affect subsequent speculative
instructions, permitting speculative store bypassing for a window of
time.
We worked around this for a number of CPUs in commits:
* 7187bb7d0b5c7dfa ("arm64: errata: Add workaround for Arm errata 3194386 and 3312417")
* 75b3c43eab594bfb ("arm64: errata: Expand speculative SSBS workaround")
Since then, similar errata have been published for a number of other Arm
Ltd CPUs, for which the same mitigation is sufficient. This is described
in their respective Software Developer Errata Notice (SDEN) documents:
* Cortex-A76 (MP052) SDEN v31.0, erratum 3324349
https://developer.arm.com/documentation/SDEN-885749/3100/
* Cortex-A77 (MP074) SDEN v19.0, erratum 3324348
https://developer.arm.com/documentation/SDEN-1152370/1900/
* Cortex-A78 (MP102) SDEN v21.0, erratum 3324344
https://developer.arm.com/documentation/SDEN-1401784/2100/
* Cortex-A78C (MP138) SDEN v16.0, erratum 3324346
https://developer.arm.com/documentation/SDEN-1707916/1600/
* Cortex-A78C (MP154) SDEN v10.0, erratum 3324347
https://developer.arm.com/documentation/SDEN-2004089/1000/
* Cortex-A725 (MP190) SDEN v5.0, erratum 3456106
https://developer.arm.com/documentation/SDEN-2832921/0500/
* Cortex-X1 (MP077) SDEN v21.0, erratum 3324344
https://developer.arm.com/documentation/SDEN-1401782/2100/
* Cortex-X1C (MP136) SDEN v16.0, erratum 3324346
https://developer.arm.com/documentation/SDEN-1707914/1600/
* Neoverse-N1 (MP050) SDEN v32.0, erratum 3324349
https://developer.arm.com/documentation/SDEN-885747/3200/
* Neoverse-V1 (MP076) SDEN v19.0, erratum 3324341
https://developer.arm.com/documentation/SDEN-1401781/1900/
Note that due to the manner in which Arm develops IP and tracks errata,
some CPUs share a common erratum number and some CPUs have multiple
erratum numbers for the same HW issue.
On parts without SB, it is necessary to use ISB for the workaround. The
spec_bar() macro used in the mitigation will expand to a "DSB SY; ISB"
sequence in this case, which is sufficient on all affected parts.
Enable the existing mitigation by adding the relevant MIDRs to
erratum_spec_ssbs_list. The list is sorted alphanumerically (involving
moving Neoverse-V3 after Neoverse-V2) so that this is easy to audit and
potentially extend again in future. The Kconfig text is also updated to
clarify the set of affected parts and the mitigation.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20240801101803.1982459-4-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[ Mark: fix conflicts in silicon-errata.rst ]
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-09 18:09:34 +08:00
|
|
|
| ARM | Cortex-A76 | #3324349 | ARM64_ERRATUM_3194386 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2020-10-29 02:28:39 +08:00
|
|
|
| ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
arm64: errata: Expand speculative SSBS workaround (again)
[ Upstream commit adeec61a4723fd3e39da68db4cc4d924e6d7f641 ]
A number of Arm Ltd CPUs suffer from errata whereby an MSR to the SSBS
special-purpose register does not affect subsequent speculative
instructions, permitting speculative store bypassing for a window of
time.
We worked around this for a number of CPUs in commits:
* 7187bb7d0b5c7dfa ("arm64: errata: Add workaround for Arm errata 3194386 and 3312417")
* 75b3c43eab594bfb ("arm64: errata: Expand speculative SSBS workaround")
Since then, similar errata have been published for a number of other Arm
Ltd CPUs, for which the same mitigation is sufficient. This is described
in their respective Software Developer Errata Notice (SDEN) documents:
* Cortex-A76 (MP052) SDEN v31.0, erratum 3324349
https://developer.arm.com/documentation/SDEN-885749/3100/
* Cortex-A77 (MP074) SDEN v19.0, erratum 3324348
https://developer.arm.com/documentation/SDEN-1152370/1900/
* Cortex-A78 (MP102) SDEN v21.0, erratum 3324344
https://developer.arm.com/documentation/SDEN-1401784/2100/
* Cortex-A78C (MP138) SDEN v16.0, erratum 3324346
https://developer.arm.com/documentation/SDEN-1707916/1600/
* Cortex-A78C (MP154) SDEN v10.0, erratum 3324347
https://developer.arm.com/documentation/SDEN-2004089/1000/
* Cortex-A725 (MP190) SDEN v5.0, erratum 3456106
https://developer.arm.com/documentation/SDEN-2832921/0500/
* Cortex-X1 (MP077) SDEN v21.0, erratum 3324344
https://developer.arm.com/documentation/SDEN-1401782/2100/
* Cortex-X1C (MP136) SDEN v16.0, erratum 3324346
https://developer.arm.com/documentation/SDEN-1707914/1600/
* Neoverse-N1 (MP050) SDEN v32.0, erratum 3324349
https://developer.arm.com/documentation/SDEN-885747/3200/
* Neoverse-V1 (MP076) SDEN v19.0, erratum 3324341
https://developer.arm.com/documentation/SDEN-1401781/1900/
Note that due to the manner in which Arm develops IP and tracks errata,
some CPUs share a common erratum number and some CPUs have multiple
erratum numbers for the same HW issue.
On parts without SB, it is necessary to use ISB for the workaround. The
spec_bar() macro used in the mitigation will expand to a "DSB SY; ISB"
sequence in this case, which is sufficient on all affected parts.
Enable the existing mitigation by adding the relevant MIDRs to
erratum_spec_ssbs_list. The list is sorted alphanumerically (involving
moving Neoverse-V3 after Neoverse-V2) so that this is easy to audit and
potentially extend again in future. The Kconfig text is also updated to
clarify the set of affected parts and the mitigation.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20240801101803.1982459-4-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[ Mark: fix conflicts in silicon-errata.rst ]
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-09 18:09:34 +08:00
|
|
|
| ARM | Cortex-A77 | #3324348 | ARM64_ERRATUM_3194386 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
|
|
|
| ARM | Cortex-A78 | #3324344 | ARM64_ERRATUM_3194386 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
|
|
|
| ARM | Cortex-A78C | #3324346,3324347| ARM64_ERRATUM_3194386 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2022-07-04 23:57:32 +08:00
|
|
|
| ARM | Cortex-A510 | #2441009 | ARM64_ERRATUM_2441009 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2022-08-19 18:30:50 +08:00
|
|
|
| ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2023-07-21 07:23:31 +08:00
|
|
|
| ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2023-08-03 01:02:22 +08:00
|
|
|
| ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2023-08-03 01:02:23 +08:00
|
|
|
| ARM | Cortex-A710 | #2224489 | ARM64_ERRATUM_2224489 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
arm64: errata: Expand speculative SSBS workaround
[ Upstream commit 75b3c43eab594bfbd8184ec8ee1a6b820950819a ]
A number of Arm Ltd CPUs suffer from errata whereby an MSR to the SSBS
special-purpose register does not affect subsequent speculative
instructions, permitting speculative store bypassing for a window of
time.
We worked around this for Cortex-X4 and Neoverse-V3, in commit:
7187bb7d0b5c7dfa ("arm64: errata: Add workaround for Arm errata 3194386 and 3312417")
... as per their Software Developer Errata Notice (SDEN) documents:
* Cortex-X4 SDEN v8.0, erratum 3194386:
https://developer.arm.com/documentation/SDEN-2432808/0800/
* Neoverse-V3 SDEN v6.0, erratum 3312417:
https://developer.arm.com/documentation/SDEN-2891958/0600/
Since then, similar errata have been published for a number of other Arm Ltd
CPUs, for which the mitigation is the same. This is described in their
respective SDEN documents:
* Cortex-A710 SDEN v19.0, errataum 3324338
https://developer.arm.com/documentation/SDEN-1775101/1900/?lang=en
* Cortex-A720 SDEN v11.0, erratum 3456091
https://developer.arm.com/documentation/SDEN-2439421/1100/?lang=en
* Cortex-X2 SDEN v19.0, erratum 3324338
https://developer.arm.com/documentation/SDEN-1775100/1900/?lang=en
* Cortex-X3 SDEN v14.0, erratum 3324335
https://developer.arm.com/documentation/SDEN-2055130/1400/?lang=en
* Cortex-X925 SDEN v8.0, erratum 3324334
https://developer.arm.com/documentation/109108/800/?lang=en
* Neoverse-N2 SDEN v17.0, erratum 3324339
https://developer.arm.com/documentation/SDEN-1982442/1700/?lang=en
* Neoverse-V2 SDEN v9.0, erratum 3324336
https://developer.arm.com/documentation/SDEN-2332927/900/?lang=en
Note that due to shared design lineage, some CPUs share the same erratum
number.
Add these to the existing mitigation under CONFIG_ARM64_ERRATUM_3194386.
As listing all of the erratum IDs in the runtime description would be
unwieldy, this is reduced to:
"SSBS not fully self-synchronizing"
... matching the description of the errata in all of the SDENs.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20240603111812.1514101-6-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[ Mark: fix conflicts and renames ]
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-09 18:09:31 +08:00
|
|
|
| ARM | Cortex-A710 | #3324338 | ARM64_ERRATUM_3194386 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
|
|
|
| ARM | Cortex-A720 | #3456091 | ARM64_ERRATUM_3194386 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
arm64: errata: Expand speculative SSBS workaround (again)
[ Upstream commit adeec61a4723fd3e39da68db4cc4d924e6d7f641 ]
A number of Arm Ltd CPUs suffer from errata whereby an MSR to the SSBS
special-purpose register does not affect subsequent speculative
instructions, permitting speculative store bypassing for a window of
time.
We worked around this for a number of CPUs in commits:
* 7187bb7d0b5c7dfa ("arm64: errata: Add workaround for Arm errata 3194386 and 3312417")
* 75b3c43eab594bfb ("arm64: errata: Expand speculative SSBS workaround")
Since then, similar errata have been published for a number of other Arm
Ltd CPUs, for which the same mitigation is sufficient. This is described
in their respective Software Developer Errata Notice (SDEN) documents:
* Cortex-A76 (MP052) SDEN v31.0, erratum 3324349
https://developer.arm.com/documentation/SDEN-885749/3100/
* Cortex-A77 (MP074) SDEN v19.0, erratum 3324348
https://developer.arm.com/documentation/SDEN-1152370/1900/
* Cortex-A78 (MP102) SDEN v21.0, erratum 3324344
https://developer.arm.com/documentation/SDEN-1401784/2100/
* Cortex-A78C (MP138) SDEN v16.0, erratum 3324346
https://developer.arm.com/documentation/SDEN-1707916/1600/
* Cortex-A78C (MP154) SDEN v10.0, erratum 3324347
https://developer.arm.com/documentation/SDEN-2004089/1000/
* Cortex-A725 (MP190) SDEN v5.0, erratum 3456106
https://developer.arm.com/documentation/SDEN-2832921/0500/
* Cortex-X1 (MP077) SDEN v21.0, erratum 3324344
https://developer.arm.com/documentation/SDEN-1401782/2100/
* Cortex-X1C (MP136) SDEN v16.0, erratum 3324346
https://developer.arm.com/documentation/SDEN-1707914/1600/
* Neoverse-N1 (MP050) SDEN v32.0, erratum 3324349
https://developer.arm.com/documentation/SDEN-885747/3200/
* Neoverse-V1 (MP076) SDEN v19.0, erratum 3324341
https://developer.arm.com/documentation/SDEN-1401781/1900/
Note that due to the manner in which Arm develops IP and tracks errata,
some CPUs share a common erratum number and some CPUs have multiple
erratum numbers for the same HW issue.
On parts without SB, it is necessary to use ISB for the workaround. The
spec_bar() macro used in the mitigation will expand to a "DSB SY; ISB"
sequence in this case, which is sufficient on all affected parts.
Enable the existing mitigation by adding the relevant MIDRs to
erratum_spec_ssbs_list. The list is sorted alphanumerically (involving
moving Neoverse-V3 after Neoverse-V2) so that this is easy to audit and
potentially extend again in future. The Kconfig text is also updated to
clarify the set of affected parts and the mitigation.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20240801101803.1982459-4-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[ Mark: fix conflicts in silicon-errata.rst ]
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-09 18:09:34 +08:00
|
|
|
| ARM | Cortex-A725 | #3456106 | ARM64_ERRATUM_3194386 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
|
|
|
| ARM | Cortex-X1 | #3324344 | ARM64_ERRATUM_3194386 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
|
|
|
| ARM | Cortex-X1C | #3324346 | ARM64_ERRATUM_3194386 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
arm64: errata: Expand speculative SSBS workaround
[ Upstream commit 75b3c43eab594bfbd8184ec8ee1a6b820950819a ]
A number of Arm Ltd CPUs suffer from errata whereby an MSR to the SSBS
special-purpose register does not affect subsequent speculative
instructions, permitting speculative store bypassing for a window of
time.
We worked around this for Cortex-X4 and Neoverse-V3, in commit:
7187bb7d0b5c7dfa ("arm64: errata: Add workaround for Arm errata 3194386 and 3312417")
... as per their Software Developer Errata Notice (SDEN) documents:
* Cortex-X4 SDEN v8.0, erratum 3194386:
https://developer.arm.com/documentation/SDEN-2432808/0800/
* Neoverse-V3 SDEN v6.0, erratum 3312417:
https://developer.arm.com/documentation/SDEN-2891958/0600/
Since then, similar errata have been published for a number of other Arm Ltd
CPUs, for which the mitigation is the same. This is described in their
respective SDEN documents:
* Cortex-A710 SDEN v19.0, errataum 3324338
https://developer.arm.com/documentation/SDEN-1775101/1900/?lang=en
* Cortex-A720 SDEN v11.0, erratum 3456091
https://developer.arm.com/documentation/SDEN-2439421/1100/?lang=en
* Cortex-X2 SDEN v19.0, erratum 3324338
https://developer.arm.com/documentation/SDEN-1775100/1900/?lang=en
* Cortex-X3 SDEN v14.0, erratum 3324335
https://developer.arm.com/documentation/SDEN-2055130/1400/?lang=en
* Cortex-X925 SDEN v8.0, erratum 3324334
https://developer.arm.com/documentation/109108/800/?lang=en
* Neoverse-N2 SDEN v17.0, erratum 3324339
https://developer.arm.com/documentation/SDEN-1982442/1700/?lang=en
* Neoverse-V2 SDEN v9.0, erratum 3324336
https://developer.arm.com/documentation/SDEN-2332927/900/?lang=en
Note that due to shared design lineage, some CPUs share the same erratum
number.
Add these to the existing mitigation under CONFIG_ARM64_ERRATUM_3194386.
As listing all of the erratum IDs in the runtime description would be
unwieldy, this is reduced to:
"SSBS not fully self-synchronizing"
... matching the description of the errata in all of the SDENs.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20240603111812.1514101-6-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[ Mark: fix conflicts and renames ]
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-09 18:09:31 +08:00
|
|
|
| ARM | Cortex-X2 | #3324338 | ARM64_ERRATUM_3194386 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
|
|
|
| ARM | Cortex-X3 | #3324335 | ARM64_ERRATUM_3194386 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2024-08-09 18:09:26 +08:00
|
|
|
| ARM | Cortex-X4 | #3194386 | ARM64_ERRATUM_3194386 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
arm64: errata: Expand speculative SSBS workaround
[ Upstream commit 75b3c43eab594bfbd8184ec8ee1a6b820950819a ]
A number of Arm Ltd CPUs suffer from errata whereby an MSR to the SSBS
special-purpose register does not affect subsequent speculative
instructions, permitting speculative store bypassing for a window of
time.
We worked around this for Cortex-X4 and Neoverse-V3, in commit:
7187bb7d0b5c7dfa ("arm64: errata: Add workaround for Arm errata 3194386 and 3312417")
... as per their Software Developer Errata Notice (SDEN) documents:
* Cortex-X4 SDEN v8.0, erratum 3194386:
https://developer.arm.com/documentation/SDEN-2432808/0800/
* Neoverse-V3 SDEN v6.0, erratum 3312417:
https://developer.arm.com/documentation/SDEN-2891958/0600/
Since then, similar errata have been published for a number of other Arm Ltd
CPUs, for which the mitigation is the same. This is described in their
respective SDEN documents:
* Cortex-A710 SDEN v19.0, errataum 3324338
https://developer.arm.com/documentation/SDEN-1775101/1900/?lang=en
* Cortex-A720 SDEN v11.0, erratum 3456091
https://developer.arm.com/documentation/SDEN-2439421/1100/?lang=en
* Cortex-X2 SDEN v19.0, erratum 3324338
https://developer.arm.com/documentation/SDEN-1775100/1900/?lang=en
* Cortex-X3 SDEN v14.0, erratum 3324335
https://developer.arm.com/documentation/SDEN-2055130/1400/?lang=en
* Cortex-X925 SDEN v8.0, erratum 3324334
https://developer.arm.com/documentation/109108/800/?lang=en
* Neoverse-N2 SDEN v17.0, erratum 3324339
https://developer.arm.com/documentation/SDEN-1982442/1700/?lang=en
* Neoverse-V2 SDEN v9.0, erratum 3324336
https://developer.arm.com/documentation/SDEN-2332927/900/?lang=en
Note that due to shared design lineage, some CPUs share the same erratum
number.
Add these to the existing mitigation under CONFIG_ARM64_ERRATUM_3194386.
As listing all of the erratum IDs in the runtime description would be
unwieldy, this is reduced to:
"SSBS not fully self-synchronizing"
... matching the description of the errata in all of the SDENs.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20240603111812.1514101-6-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[ Mark: fix conflicts and renames ]
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-09 18:09:31 +08:00
|
|
|
| ARM | Cortex-X925 | #3324334 | ARM64_ERRATUM_3194386 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-05-23 18:24:50 +08:00
|
|
|
| ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-06-18 23:17:38 +08:00
|
|
|
| ARM | Neoverse-N1 | #1349291 | N/A |
|
2019-07-13 06:35:14 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-10-18 01:42:58 +08:00
|
|
|
| ARM | Neoverse-N1 | #1542419 | ARM64_ERRATUM_1542419 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
arm64: errata: Expand speculative SSBS workaround (again)
[ Upstream commit adeec61a4723fd3e39da68db4cc4d924e6d7f641 ]
A number of Arm Ltd CPUs suffer from errata whereby an MSR to the SSBS
special-purpose register does not affect subsequent speculative
instructions, permitting speculative store bypassing for a window of
time.
We worked around this for a number of CPUs in commits:
* 7187bb7d0b5c7dfa ("arm64: errata: Add workaround for Arm errata 3194386 and 3312417")
* 75b3c43eab594bfb ("arm64: errata: Expand speculative SSBS workaround")
Since then, similar errata have been published for a number of other Arm
Ltd CPUs, for which the same mitigation is sufficient. This is described
in their respective Software Developer Errata Notice (SDEN) documents:
* Cortex-A76 (MP052) SDEN v31.0, erratum 3324349
https://developer.arm.com/documentation/SDEN-885749/3100/
* Cortex-A77 (MP074) SDEN v19.0, erratum 3324348
https://developer.arm.com/documentation/SDEN-1152370/1900/
* Cortex-A78 (MP102) SDEN v21.0, erratum 3324344
https://developer.arm.com/documentation/SDEN-1401784/2100/
* Cortex-A78C (MP138) SDEN v16.0, erratum 3324346
https://developer.arm.com/documentation/SDEN-1707916/1600/
* Cortex-A78C (MP154) SDEN v10.0, erratum 3324347
https://developer.arm.com/documentation/SDEN-2004089/1000/
* Cortex-A725 (MP190) SDEN v5.0, erratum 3456106
https://developer.arm.com/documentation/SDEN-2832921/0500/
* Cortex-X1 (MP077) SDEN v21.0, erratum 3324344
https://developer.arm.com/documentation/SDEN-1401782/2100/
* Cortex-X1C (MP136) SDEN v16.0, erratum 3324346
https://developer.arm.com/documentation/SDEN-1707914/1600/
* Neoverse-N1 (MP050) SDEN v32.0, erratum 3324349
https://developer.arm.com/documentation/SDEN-885747/3200/
* Neoverse-V1 (MP076) SDEN v19.0, erratum 3324341
https://developer.arm.com/documentation/SDEN-1401781/1900/
Note that due to the manner in which Arm develops IP and tracks errata,
some CPUs share a common erratum number and some CPUs have multiple
erratum numbers for the same HW issue.
On parts without SB, it is necessary to use ISB for the workaround. The
spec_bar() macro used in the mitigation will expand to a "DSB SY; ISB"
sequence in this case, which is sufficient on all affected parts.
Enable the existing mitigation by adding the relevant MIDRs to
erratum_spec_ssbs_list. The list is sorted alphanumerically (involving
moving Neoverse-V3 after Neoverse-V2) so that this is easy to audit and
potentially extend again in future. The Kconfig text is also updated to
clarify the set of affected parts and the mitigation.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20240801101803.1982459-4-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[ Mark: fix conflicts in silicon-errata.rst ]
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-09 18:09:34 +08:00
|
|
|
| ARM | Neoverse-N1 | #3324349 | ARM64_ERRATUM_3194386 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2023-07-21 07:23:31 +08:00
|
|
|
| ARM | Neoverse-N2 | #2139208 | ARM64_ERRATUM_2139208 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2023-08-03 01:02:22 +08:00
|
|
|
| ARM | Neoverse-N2 | #2067961 | ARM64_ERRATUM_2067961 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2023-08-03 01:02:23 +08:00
|
|
|
| ARM | Neoverse-N2 | #2253138 | ARM64_ERRATUM_2253138 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
arm64: errata: Expand speculative SSBS workaround
[ Upstream commit 75b3c43eab594bfbd8184ec8ee1a6b820950819a ]
A number of Arm Ltd CPUs suffer from errata whereby an MSR to the SSBS
special-purpose register does not affect subsequent speculative
instructions, permitting speculative store bypassing for a window of
time.
We worked around this for Cortex-X4 and Neoverse-V3, in commit:
7187bb7d0b5c7dfa ("arm64: errata: Add workaround for Arm errata 3194386 and 3312417")
... as per their Software Developer Errata Notice (SDEN) documents:
* Cortex-X4 SDEN v8.0, erratum 3194386:
https://developer.arm.com/documentation/SDEN-2432808/0800/
* Neoverse-V3 SDEN v6.0, erratum 3312417:
https://developer.arm.com/documentation/SDEN-2891958/0600/
Since then, similar errata have been published for a number of other Arm Ltd
CPUs, for which the mitigation is the same. This is described in their
respective SDEN documents:
* Cortex-A710 SDEN v19.0, errataum 3324338
https://developer.arm.com/documentation/SDEN-1775101/1900/?lang=en
* Cortex-A720 SDEN v11.0, erratum 3456091
https://developer.arm.com/documentation/SDEN-2439421/1100/?lang=en
* Cortex-X2 SDEN v19.0, erratum 3324338
https://developer.arm.com/documentation/SDEN-1775100/1900/?lang=en
* Cortex-X3 SDEN v14.0, erratum 3324335
https://developer.arm.com/documentation/SDEN-2055130/1400/?lang=en
* Cortex-X925 SDEN v8.0, erratum 3324334
https://developer.arm.com/documentation/109108/800/?lang=en
* Neoverse-N2 SDEN v17.0, erratum 3324339
https://developer.arm.com/documentation/SDEN-1982442/1700/?lang=en
* Neoverse-V2 SDEN v9.0, erratum 3324336
https://developer.arm.com/documentation/SDEN-2332927/900/?lang=en
Note that due to shared design lineage, some CPUs share the same erratum
number.
Add these to the existing mitigation under CONFIG_ARM64_ERRATUM_3194386.
As listing all of the erratum IDs in the runtime description would be
unwieldy, this is reduced to:
"SSBS not fully self-synchronizing"
... matching the description of the errata in all of the SDENs.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20240603111812.1514101-6-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[ Mark: fix conflicts and renames ]
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-09 18:09:31 +08:00
|
|
|
| ARM | Neoverse-N2 | #3324339 | ARM64_ERRATUM_3194386 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
arm64: errata: Expand speculative SSBS workaround (again)
[ Upstream commit adeec61a4723fd3e39da68db4cc4d924e6d7f641 ]
A number of Arm Ltd CPUs suffer from errata whereby an MSR to the SSBS
special-purpose register does not affect subsequent speculative
instructions, permitting speculative store bypassing for a window of
time.
We worked around this for a number of CPUs in commits:
* 7187bb7d0b5c7dfa ("arm64: errata: Add workaround for Arm errata 3194386 and 3312417")
* 75b3c43eab594bfb ("arm64: errata: Expand speculative SSBS workaround")
Since then, similar errata have been published for a number of other Arm
Ltd CPUs, for which the same mitigation is sufficient. This is described
in their respective Software Developer Errata Notice (SDEN) documents:
* Cortex-A76 (MP052) SDEN v31.0, erratum 3324349
https://developer.arm.com/documentation/SDEN-885749/3100/
* Cortex-A77 (MP074) SDEN v19.0, erratum 3324348
https://developer.arm.com/documentation/SDEN-1152370/1900/
* Cortex-A78 (MP102) SDEN v21.0, erratum 3324344
https://developer.arm.com/documentation/SDEN-1401784/2100/
* Cortex-A78C (MP138) SDEN v16.0, erratum 3324346
https://developer.arm.com/documentation/SDEN-1707916/1600/
* Cortex-A78C (MP154) SDEN v10.0, erratum 3324347
https://developer.arm.com/documentation/SDEN-2004089/1000/
* Cortex-A725 (MP190) SDEN v5.0, erratum 3456106
https://developer.arm.com/documentation/SDEN-2832921/0500/
* Cortex-X1 (MP077) SDEN v21.0, erratum 3324344
https://developer.arm.com/documentation/SDEN-1401782/2100/
* Cortex-X1C (MP136) SDEN v16.0, erratum 3324346
https://developer.arm.com/documentation/SDEN-1707914/1600/
* Neoverse-N1 (MP050) SDEN v32.0, erratum 3324349
https://developer.arm.com/documentation/SDEN-885747/3200/
* Neoverse-V1 (MP076) SDEN v19.0, erratum 3324341
https://developer.arm.com/documentation/SDEN-1401781/1900/
Note that due to the manner in which Arm develops IP and tracks errata,
some CPUs share a common erratum number and some CPUs have multiple
erratum numbers for the same HW issue.
On parts without SB, it is necessary to use ISB for the workaround. The
spec_bar() macro used in the mitigation will expand to a "DSB SY; ISB"
sequence in this case, which is sufficient on all affected parts.
Enable the existing mitigation by adding the relevant MIDRs to
erratum_spec_ssbs_list. The list is sorted alphanumerically (involving
moving Neoverse-V3 after Neoverse-V2) so that this is easy to audit and
potentially extend again in future. The Kconfig text is also updated to
clarify the set of affected parts and the mitigation.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20240801101803.1982459-4-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[ Mark: fix conflicts in silicon-errata.rst ]
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-09 18:09:34 +08:00
|
|
|
| ARM | Neoverse-V1 | #3324341 | ARM64_ERRATUM_3194386 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
arm64: errata: Expand speculative SSBS workaround
[ Upstream commit 75b3c43eab594bfbd8184ec8ee1a6b820950819a ]
A number of Arm Ltd CPUs suffer from errata whereby an MSR to the SSBS
special-purpose register does not affect subsequent speculative
instructions, permitting speculative store bypassing for a window of
time.
We worked around this for Cortex-X4 and Neoverse-V3, in commit:
7187bb7d0b5c7dfa ("arm64: errata: Add workaround for Arm errata 3194386 and 3312417")
... as per their Software Developer Errata Notice (SDEN) documents:
* Cortex-X4 SDEN v8.0, erratum 3194386:
https://developer.arm.com/documentation/SDEN-2432808/0800/
* Neoverse-V3 SDEN v6.0, erratum 3312417:
https://developer.arm.com/documentation/SDEN-2891958/0600/
Since then, similar errata have been published for a number of other Arm Ltd
CPUs, for which the mitigation is the same. This is described in their
respective SDEN documents:
* Cortex-A710 SDEN v19.0, errataum 3324338
https://developer.arm.com/documentation/SDEN-1775101/1900/?lang=en
* Cortex-A720 SDEN v11.0, erratum 3456091
https://developer.arm.com/documentation/SDEN-2439421/1100/?lang=en
* Cortex-X2 SDEN v19.0, erratum 3324338
https://developer.arm.com/documentation/SDEN-1775100/1900/?lang=en
* Cortex-X3 SDEN v14.0, erratum 3324335
https://developer.arm.com/documentation/SDEN-2055130/1400/?lang=en
* Cortex-X925 SDEN v8.0, erratum 3324334
https://developer.arm.com/documentation/109108/800/?lang=en
* Neoverse-N2 SDEN v17.0, erratum 3324339
https://developer.arm.com/documentation/SDEN-1982442/1700/?lang=en
* Neoverse-V2 SDEN v9.0, erratum 3324336
https://developer.arm.com/documentation/SDEN-2332927/900/?lang=en
Note that due to shared design lineage, some CPUs share the same erratum
number.
Add these to the existing mitigation under CONFIG_ARM64_ERRATUM_3194386.
As listing all of the erratum IDs in the runtime description would be
unwieldy, this is reduced to:
"SSBS not fully self-synchronizing"
... matching the description of the errata in all of the SDENs.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20240603111812.1514101-6-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[ Mark: fix conflicts and renames ]
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-09 18:09:31 +08:00
|
|
|
| ARM | Neoverse-V2 | #3324336 | ARM64_ERRATUM_3194386 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2024-08-09 18:09:30 +08:00
|
|
|
| ARM | Neoverse-V3 | #3312417 | ARM64_ERRATUM_3194386 |
|
2024-08-09 18:09:26 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-05-23 18:24:50 +08:00
|
|
|
| ARM | MMU-500 | #841119,826419 | N/A |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2023-08-03 01:02:27 +08:00
|
|
|
| ARM | MMU-600 | #1076982,1209401| N/A |
|
2023-08-03 01:02:24 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2023-08-03 01:02:27 +08:00
|
|
|
| ARM | MMU-700 | #2268618,2812531| N/A |
|
2023-08-03 01:02:25 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-11-01 05:47:23 +08:00
|
|
|
| Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_845719 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-11-01 05:47:25 +08:00
|
|
|
| Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_843419 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-11-01 05:47:23 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-05-23 18:24:50 +08:00
|
|
|
| Cavium | ThunderX ITS | #22375,24313 | CAVIUM_ERRATUM_22375 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-02-10 01:00:34 +08:00
|
|
|
| Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-02-10 01:00:34 +08:00
|
|
|
| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2020-03-11 19:56:49 +08:00
|
|
|
| Cavium | ThunderX GICv3 | #38539 | N/A |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-02-10 01:00:34 +08:00
|
|
|
| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-06-09 19:49:48 +08:00
|
|
|
| Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-02-10 01:00:34 +08:00
|
|
|
| Cavium | ThunderX SMMUv2 | #27704 | N/A |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-06-22 20:05:37 +08:00
|
|
|
| Cavium | ThunderX2 SMMUv3| #74 | N/A |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-06-23 21:34:36 +08:00
|
|
|
| Cavium | ThunderX2 SMMUv3| #126 | N/A |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-09-13 17:57:50 +08:00
|
|
|
| Cavium | ThunderX2 Core | #219 | CAVIUM_TX2_ERRATUM_219 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2020-07-15 15:06:47 +08:00
|
|
|
| Marvell | ARM-MMU-500 | #582743 | N/A |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2021-03-24 08:28:09 +08:00
|
|
|
| NVIDIA | Carmel Core | N/A | NVIDIA_CARMEL_CNP_ERRATUM |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-02-10 01:00:34 +08:00
|
|
|
| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-02-10 01:00:34 +08:00
|
|
|
| Hisilicon | Hip0{5,6,7} | #161010101 | HISILICON_ERRATUM_161010101 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-05-17 17:12:05 +08:00
|
|
|
| Hisilicon | Hip0{6,7} | #161010701 | N/A |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-08-01 00:29:33 +08:00
|
|
|
| Hisilicon | Hip0{6,7} | #161010803 | N/A |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-07-29 04:20:37 +08:00
|
|
|
| Hisilicon | Hip07 | #161600802 | HISILICON_ERRATUM_161600802 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-03-26 23:17:53 +08:00
|
|
|
| Hisilicon | Hip08 SMMU PMCG | #162001800 | N/A |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2023-08-14 20:40:12 +08:00
|
|
|
| Hisilicon | Hip08 SMMU PMCG | #162001900 | N/A |
|
|
|
|
| | Hip09 SMMU PMCG | | |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-12-14 06:19:37 +08:00
|
|
|
| Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-10-30 07:27:38 +08:00
|
|
|
| Qualcomm Tech. | Kryo/Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-03-07 22:20:38 +08:00
|
|
|
| Qualcomm Tech. | QDF2400 ITS | E0065 | QCOM_QDF2400_ERRATUM_0065 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2017-12-12 06:42:32 +08:00
|
|
|
| Qualcomm Tech. | Falkor v{1,2} | E1041 | QCOM_FALKOR_ERRATUM_1041 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2020-07-01 02:00:54 +08:00
|
|
|
| Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1463225 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
|
|
|
| Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1418040 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2020-07-01 02:00:55 +08:00
|
|
|
| Qualcomm Tech. | Kryo4xx Silver | N/A | ARM64_ERRATUM_1530923 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
|
|
|
| Qualcomm Tech. | Kryo4xx Silver | N/A | ARM64_ERRATUM_1024718 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2022-05-12 19:01:34 +08:00
|
|
|
| Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1286807 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
|
|
|
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2019-02-27 02:43:41 +08:00
|
|
|
| Fujitsu | A64FX | E#010001 | FUJITSU_ERRATUM_010001 |
|
2019-06-13 01:52:38 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
2024-02-15 01:55:18 +08:00
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
|
|
|
| Microsoft | Azure Cobalt 100| #2139208 | ARM64_ERRATUM_2139208 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
|
|
|
| Microsoft | Azure Cobalt 100| #2067961 | ARM64_ERRATUM_2067961 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|
|
|
|
| Microsoft | Azure Cobalt 100| #2253138 | ARM64_ERRATUM_2253138 |
|
|
|
|
+----------------+-----------------+-----------------+-----------------------------+
|