arm64: errata: Mitigate Ampere1 erratum AC03_CPU_38 at stage-2

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

diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst
index 55492fea4427686ddb8bca4554be91e83b23213c..bbc80eff03f98006366fc2b83cc94cad8a8aa898 100644 (file)
--- 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 20ee745c118aeefa2346aef8b133a37458940113..d5eb2fbab473e459bba2ec2b5fb934db44f4bc0c 100644 (file)
--- 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 89ac00084f38a4584924bd2da8e2e0e9c5341a07..8dbf3c21ea22a57a23146e5c7098200b01eb34be 100644 (file)
--- 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 8f37e65c23eeaea18dd85ed3415172715c94cebe..ae5f6b5ac80fd385e24f6c7f28034f1fb14602ae 100644 (file)
--- 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 f1c0347ec31a85c7c85dcb2d969def4aee154f06..14d31d1b2ff029a8b90c0cbd0c4a6ca8a3e7d270 100644 (file)
--- 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