+++ /dev/null
-From 8829ccb3b9c4bcfd84dfaecb9a49ea18101de3f4 Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Fri, 9 Jun 2023 22:01:02 +0000
-Subject: arm64: errata: Mitigate Ampere1 erratum AC03_CPU_38 at stage-2
-
-From: Oliver Upton <oliver.upton@linux.dev>
-
-[ Upstream commit 6df696cd9bc1ceed0e92e36908f88bbd16d18255 ]
-
-AmpereOne has an erratum in its implementation of FEAT_HAFDBS that
-required disabling the feature on the design. This was done by reporting
-the feature as not implemented in the ID register, although the
-corresponding control bits were not actually RES0. This does not align
-well with the requirements of the architecture, which mandates these
-bits be RES0 if HAFDBS isn't implemented.
-
-The kernel's use of stage-1 is unaffected, as the HA and HD bits are
-only set if HAFDBS is detected in the ID register. KVM, on the other
-hand, relies on the RES0 behavior at stage-2 to use the same value for
-VTCR_EL2 on any cpu in the system. Mitigate the non-RES0 behavior by
-leaving VTCR_EL2.HA clear on affected systems.
-
-Cc: stable@vger.kernel.org
-Cc: D Scott Phillips <scott@os.amperecomputing.com>
-Cc: Darren Hart <darren@os.amperecomputing.com>
-Acked-by: D Scott Phillips <scott@os.amperecomputing.com>
-Acked-by: Catalin Marinas <catalin.marinas@arm.com>
-Link: https://lore.kernel.org/r/20230609220104.1836988-2-oliver.upton@linux.dev
-Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- Documentation/arm64/silicon-errata.rst | 3 +++
- arch/arm64/Kconfig | 19 +++++++++++++++++++
- arch/arm64/kernel/cpu_errata.c | 7 +++++++
- arch/arm64/kvm/hyp/pgtable.c | 14 +++++++++++---
- arch/arm64/tools/cpucaps | 1 +
- 5 files changed, 41 insertions(+), 3 deletions(-)
-
-diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst
-index 55492fea44276..bbc80eff03f98 100644
---- a/Documentation/arm64/silicon-errata.rst
-+++ b/Documentation/arm64/silicon-errata.rst
-@@ -52,6 +52,9 @@ stable kernels.
- | Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 |
- +----------------+-----------------+-----------------+-----------------------------+
- +----------------+-----------------+-----------------+-----------------------------+
-+| Ampere | AmpereOne | AC03_CPU_38 | AMPERE_ERRATUM_AC03_CPU_38 |
-++----------------+-----------------+-----------------+-----------------------------+
-++----------------+-----------------+-----------------+-----------------------------+
- | ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 |
- +----------------+-----------------+-----------------+-----------------------------+
- | ARM | Cortex-A510 | #2064142 | ARM64_ERRATUM_2064142 |
-diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
-index 20ee745c118ae..d5eb2fbab473e 100644
---- a/arch/arm64/Kconfig
-+++ b/arch/arm64/Kconfig
-@@ -376,6 +376,25 @@ menu "Kernel Features"
-
- menu "ARM errata workarounds via the alternatives framework"
-
-+config AMPERE_ERRATUM_AC03_CPU_38
-+ bool "AmpereOne: AC03_CPU_38: Certain bits in the Virtualization Translation Control Register and Translation Control Registers do not follow RES0 semantics"
-+ default y
-+ help
-+ This option adds an alternative code sequence to work around Ampere
-+ erratum AC03_CPU_38 on AmpereOne.
-+
-+ The affected design reports FEAT_HAFDBS as not implemented in
-+ ID_AA64MMFR1_EL1.HAFDBS, but (V)TCR_ELx.{HA,HD} are not RES0
-+ as required by the architecture. The unadvertised HAFDBS
-+ implementation suffers from an additional erratum where hardware
-+ A/D updates can occur after a PTE has been marked invalid.
-+
-+ The workaround forces KVM to explicitly set VTCR_EL2.HA to 0,
-+ which avoids enabling unadvertised hardware Access Flag management
-+ at stage-2.
-+
-+ If unsure, say Y.
-+
- config ARM64_WORKAROUND_CLEAN_CACHE
- bool
-
-diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
-index 89ac00084f38a..8dbf3c21ea22a 100644
---- a/arch/arm64/kernel/cpu_errata.c
-+++ b/arch/arm64/kernel/cpu_errata.c
-@@ -722,6 +722,13 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
- MIDR_FIXED(MIDR_CPU_VAR_REV(1,1), BIT(25)),
- .cpu_enable = cpu_clear_bf16_from_user_emulation,
- },
-+#endif
-+#ifdef CONFIG_AMPERE_ERRATUM_AC03_CPU_38
-+ {
-+ .desc = "AmpereOne erratum AC03_CPU_38",
-+ .capability = ARM64_WORKAROUND_AMPERE_AC03_CPU_38,
-+ ERRATA_MIDR_ALL_VERSIONS(MIDR_AMPERE1),
-+ },
- #endif
- {
- }
-diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
-index 8f37e65c23eea..ae5f6b5ac80fd 100644
---- a/arch/arm64/kvm/hyp/pgtable.c
-+++ b/arch/arm64/kvm/hyp/pgtable.c
-@@ -598,10 +598,18 @@ u64 kvm_get_vtcr(u64 mmfr0, u64 mmfr1, u32 phys_shift)
- #ifdef CONFIG_ARM64_HW_AFDBM
- /*
- * Enable the Hardware Access Flag management, unconditionally
-- * on all CPUs. The features is RES0 on CPUs without the support
-- * and must be ignored by the CPUs.
-+ * on all CPUs. In systems that have asymmetric support for the feature
-+ * this allows KVM to leverage hardware support on the subset of cores
-+ * that implement the feature.
-+ *
-+ * The architecture requires VTCR_EL2.HA to be RES0 (thus ignored by
-+ * hardware) on implementations that do not advertise support for the
-+ * feature. As such, setting HA unconditionally is safe, unless you
-+ * happen to be running on a design that has unadvertised support for
-+ * HAFDBS. Here be dragons.
- */
-- vtcr |= VTCR_EL2_HA;
-+ if (!cpus_have_final_cap(ARM64_WORKAROUND_AMPERE_AC03_CPU_38))
-+ vtcr |= VTCR_EL2_HA;
- #endif /* CONFIG_ARM64_HW_AFDBM */
-
- /* Set the vmid bits */
-diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
-index f1c0347ec31a8..14d31d1b2ff02 100644
---- a/arch/arm64/tools/cpucaps
-+++ b/arch/arm64/tools/cpucaps
-@@ -71,6 +71,7 @@ WORKAROUND_2064142
- WORKAROUND_2077057
- WORKAROUND_2457168
- WORKAROUND_2658417
-+WORKAROUND_AMPERE_AC03_CPU_38
- WORKAROUND_TRBE_OVERWRITE_FILL_MODE
- WORKAROUND_TSB_FLUSH_FAILURE
- WORKAROUND_TRBE_WRITE_OUT_OF_RANGE
---
-2.39.2
-
projects / thirdparty / kernel / stable-queue.git / commitdiff
