--- /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
