[PATCH v4] arm64: errata: Work around AmpereOne's erratum AC04_CPU_23

[PATCH v4] arm64: errata: Work around AmpereOne's erratum AC04_CPU_23

[D Scott Phillips]

On AmpereOne AC04, updates to HCR_EL2 can rarely corrupt simultaneous
translations for data addresses initiated by load/store instructions.
Only instruction initiated translations are vulnerable, not translations
from prefetches for example. A DSB before the store to HCR_EL2 is
sufficient to prevent older instructions from hitting the window for
corruption, and an ISB after is sufficient to prevent younger
instructions from hitting the window for corruption.

Signed-off-by: D Scott Phillips <scott@os.amperecomputing.com>
Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
---
v3: https://lore.kernel.org/kvmarm/20250508210009.428998-1-scott@os.amperecomputing.com/
Changes since v3:
 - Added entry in silicon-errata.rst (Marc)

v2: https://lore.kernel.org/kvmarm/20250425024741.1309893-1-scott@os.amperecomputing.com/
Changes since v2:
 - Apply the workaround before alternatives are applied (Marc)
 - Also catch stores to HCR_EL2 in assembly files (Marc)
 - Added a sysreg_clear_set_hcr() helper for the HCR_EL2 fiddling in
   vgic-v3-sr.c that I had previously missed.

v1: https://lore.kernel.org/kvmarm/20250415154711.1698544-2-scott@os.amperecomputing.com/
Changes since v1:
 - Add a write_sysreg_hcr() helper (Oliver)
 - Add more specific wording in the errata description (Oliver & Marc)

 Documentation/arch/arm64/silicon-errata.rst |  2 ++
 arch/arm64/Kconfig                          | 17 +++++++++++++
 arch/arm64/include/asm/el2_setup.h          |  2 +-
 arch/arm64/include/asm/hardirq.h            |  4 +--
 arch/arm64/include/asm/sysreg.h             | 27 +++++++++++++++++++++
 arch/arm64/kernel/cpu_errata.c              | 14 +++++++++++
 arch/arm64/kernel/hyp-stub.S                |  2 +-
 arch/arm64/kvm/at.c                         |  8 +++---
 arch/arm64/kvm/hyp/include/hyp/switch.h     |  2 +-
 arch/arm64/kvm/hyp/nvhe/host.S              |  2 +-
 arch/arm64/kvm/hyp/nvhe/hyp-init.S          |  4 +--
 arch/arm64/kvm/hyp/nvhe/mem_protect.c       |  2 +-
 arch/arm64/kvm/hyp/nvhe/switch.c            |  2 +-
 arch/arm64/kvm/hyp/vgic-v3-sr.c             |  4 +--
 arch/arm64/kvm/hyp/vhe/switch.c             |  2 +-
 arch/arm64/kvm/hyp/vhe/tlb.c                |  4 +--
 arch/arm64/tools/cpucaps                    |  1 +
 17 files changed, 80 insertions(+), 19 deletions(-)

diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
index f968c13b46a78..b18ef4064bc04 100644
--- a/Documentation/arch/arm64/silicon-errata.rst
+++ b/Documentation/arch/arm64/silicon-errata.rst
@@ -57,6 +57,8 @@ stable kernels.
 +----------------+-----------------+-----------------+-----------------------------+
 | Ampere         | AmpereOne AC04  | AC04_CPU_10     | AMPERE_ERRATUM_AC03_CPU_38  |
 +----------------+-----------------+-----------------+-----------------------------+
+| Ampere         | AmpereOne AC04  | AC04_CPU_23     | AMPERE_ERRATUM_AC04_CPU_23  |
++----------------+-----------------+-----------------+-----------------------------+
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM            | Cortex-A510     | #2457168        | ARM64_ERRATUM_2457168       |
 +----------------+-----------------+-----------------+-----------------------------+
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index a182295e6f08b..3ae4e80e3002b 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -464,6 +464,23 @@ config AMPERE_ERRATUM_AC03_CPU_38
 
 	  If unsure, say Y.
 
+config AMPERE_ERRATUM_AC04_CPU_23
+        bool "AmpereOne: AC04_CPU_23:  Failure to synchronize writes to HCR_EL2 may corrupt address translations."
+	default y
+	help
+	  This option adds an alternative code sequence to work around Ampere
+	  errata AC04_CPU_23 on AmpereOne.
+
+	  Updates to HCR_EL2 can rarely corrupt simultaneous translations for
+	  data addresses initiated by load/store instructions. Only
+	  instruction initiated translations are vulnerable, not translations
+	  from prefetches for example. A DSB before the store to HCR_EL2 is
+	  sufficient to prevent older instructions from hitting the window
+	  for corruption, and an ISB after is sufficient to prevent younger
+	  instructions from hitting the window for corruption.
+
+	  If unsure, say Y.
+
 config ARM64_WORKAROUND_CLEAN_CACHE
 	bool
 
diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h
index ebceaae3c749b..2500fd0a1f66a 100644
--- a/arch/arm64/include/asm/el2_setup.h
+++ b/arch/arm64/include/asm/el2_setup.h
@@ -38,7 +38,7 @@
 
 	orr	x0, x0, #HCR_E2H
 .LnVHE_\@:
-	msr	hcr_el2, x0
+	msr_hcr_el2 x0
 	isb
 .endm
 
diff --git a/arch/arm64/include/asm/hardirq.h b/arch/arm64/include/asm/hardirq.h
index cbfa7b6f2e098..77d6b8c63d4e6 100644
--- a/arch/arm64/include/asm/hardirq.h
+++ b/arch/arm64/include/asm/hardirq.h
@@ -41,7 +41,7 @@ do {									\
 									\
 	___hcr = read_sysreg(hcr_el2);					\
 	if (!(___hcr & HCR_TGE)) {					\
-		write_sysreg(___hcr | HCR_TGE, hcr_el2);		\
+		write_sysreg_hcr(___hcr | HCR_TGE);			\
 		isb();							\
 	}								\
 	/*								\
@@ -82,7 +82,7 @@ do {									\
 	 */								\
 	barrier();							\
 	if (!___ctx->cnt && !(___hcr & HCR_TGE))			\
-		write_sysreg(___hcr, hcr_el2);				\
+		write_sysreg_hcr(___hcr);				\
 } while (0)
 
 static inline void ack_bad_irq(unsigned int irq)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 2639d3633073d..7284828f0dc9e 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -1091,6 +1091,15 @@
 	__emit_inst(0xd5000000|(\sreg)|(.L__gpr_num_\rt))
 	.endm
 
+	.macro	msr_hcr_el2, reg
+#if IS_ENABLED(CONFIG_AMPERE_ERRATUM_AC04_CPU_23)
+	dsb	nsh
+	msr	hcr_el2, \reg
+	isb
+#else
+	msr	hcr_el2, \reg
+#endif
+	.endm
 #else
 
 #include <linux/bitfield.h>
@@ -1178,6 +1187,13 @@
 		write_sysreg(__scs_new, sysreg);			\
 } while (0)
 
+#define sysreg_clear_set_hcr(clear, set) do {				\
+	u64 __scs_val = read_sysreg(hcr_el2);				\
+	u64 __scs_new = (__scs_val & ~(u64)(clear)) | (set);		\
+	if (__scs_new != __scs_val)					\
+		write_sysreg_hcr(__scs_new);			\
+} while (0)
+
 #define sysreg_clear_set_s(sysreg, clear, set) do {			\
 	u64 __scs_val = read_sysreg_s(sysreg);				\
 	u64 __scs_new = (__scs_val & ~(u64)(clear)) | (set);		\
@@ -1185,6 +1201,17 @@
 		write_sysreg_s(__scs_new, sysreg);			\
 } while (0)
 
+#define write_sysreg_hcr(__val) do {					\
+	if (IS_ENABLED(CONFIG_AMPERE_ERRATUM_AC04_CPU_23) &&		\
+	   (!system_capabilities_finalized() ||				\
+	    alternative_has_cap_unlikely(ARM64_WORKAROUND_AMPERE_AC04_CPU_23))) \
+		asm volatile("dsb nsh; msr hcr_el2, %x0; isb"		\
+			     : : "rZ" (__val));				\
+	else								\
+		asm volatile("msr hcr_el2, %x0"				\
+			     : : "rZ" (__val));				\
+} while (0)
+
 #define read_sysreg_par() ({						\
 	u64 par;							\
 	asm(ALTERNATIVE("nop", "dmb sy", ARM64_WORKAROUND_1508412));	\
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 6b0ad5070d3e0..59d723c9ab8f5 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -557,6 +557,13 @@ static const struct midr_range erratum_ac03_cpu_38_list[] = {
 };
 #endif
 
+#ifdef CONFIG_AMPERE_ERRATUM_AC04_CPU_23
+static const struct midr_range erratum_ac04_cpu_23_list[] = {
+	MIDR_ALL_VERSIONS(MIDR_AMPERE1A),
+	{},
+};
+#endif
+
 const struct arm64_cpu_capabilities arm64_errata[] = {
 #ifdef CONFIG_ARM64_WORKAROUND_CLEAN_CACHE
 	{
@@ -875,6 +882,13 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
 		.capability = ARM64_WORKAROUND_AMPERE_AC03_CPU_38,
 		ERRATA_MIDR_RANGE_LIST(erratum_ac03_cpu_38_list),
 	},
+#endif
+#ifdef CONFIG_AMPERE_ERRATUM_AC04_CPU_23
+	{
+		.desc = "AmpereOne erratum AC04_CPU_23",
+		.capability = ARM64_WORKAROUND_AMPERE_AC04_CPU_23,
+		ERRATA_MIDR_RANGE_LIST(erratum_ac04_cpu_23_list),
+	},
 #endif
 	{
 		.desc = "Broken CNTVOFF_EL2",
diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
index ae990da1eae5a..36e2d26b54f5c 100644
--- a/arch/arm64/kernel/hyp-stub.S
+++ b/arch/arm64/kernel/hyp-stub.S
@@ -97,7 +97,7 @@ SYM_CODE_START_LOCAL(__finalise_el2)
 2:
 	// Engage the VHE magic!
 	mov_q	x0, HCR_HOST_VHE_FLAGS
-	msr	hcr_el2, x0
+	msr_hcr_el2 x0
 	isb
 
 	// Use the EL1 allocated stack, per-cpu offset
diff --git a/arch/arm64/kvm/at.c b/arch/arm64/kvm/at.c
index f74a66ce3064b..9c13e70fadf5e 100644
--- a/arch/arm64/kvm/at.c
+++ b/arch/arm64/kvm/at.c
@@ -516,7 +516,7 @@ static void __mmu_config_save(struct mmu_config *config)
 
 static void __mmu_config_restore(struct mmu_config *config)
 {
-	write_sysreg(config->hcr,	hcr_el2);
+	write_sysreg_hcr(config->hcr);
 
 	/*
 	 * ARM errata 1165522 and 1530923 require TGE to be 1 before
@@ -1267,7 +1267,7 @@ static u64 __kvm_at_s1e01_fast(struct kvm_vcpu *vcpu, u32 op, u64 vaddr)
 
 skip_mmu_switch:
 	/* Clear TGE, enable S2 translation, we're rolling */
-	write_sysreg((config.hcr & ~HCR_TGE) | HCR_VM,	hcr_el2);
+	write_sysreg_hcr((config.hcr & ~HCR_TGE) | HCR_VM);
 	isb();
 
 	switch (op) {
@@ -1350,7 +1350,7 @@ void __kvm_at_s1e2(struct kvm_vcpu *vcpu, u32 op, u64 vaddr)
 		if (!vcpu_el2_e2h_is_set(vcpu))
 			val |= HCR_NV | HCR_NV1;
 
-		write_sysreg(val, hcr_el2);
+		write_sysreg_hcr(val);
 		isb();
 
 		par = SYS_PAR_EL1_F;
@@ -1375,7 +1375,7 @@ void __kvm_at_s1e2(struct kvm_vcpu *vcpu, u32 op, u64 vaddr)
 		if (!fail)
 			par = read_sysreg_par();
 
-		write_sysreg(hcr, hcr_el2);
+		write_sysreg_hcr(hcr);
 		isb();
 	}
 
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index b741ea6aefa58..06aa37dbc957d 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -301,7 +301,7 @@ static inline void ___activate_traps(struct kvm_vcpu *vcpu, u64 hcr)
 	if (cpus_have_final_cap(ARM64_WORKAROUND_CAVIUM_TX2_219_TVM))
 		hcr |= HCR_TVM;
 
-	write_sysreg(hcr, hcr_el2);
+	write_sysreg_hcr(hcr);
 
 	if (cpus_have_final_cap(ARM64_HAS_RAS_EXTN) && (hcr & HCR_VSE))
 		write_sysreg_s(vcpu->arch.vsesr_el2, SYS_VSESR_EL2);
diff --git a/arch/arm64/kvm/hyp/nvhe/host.S b/arch/arm64/kvm/hyp/nvhe/host.S
index 58f0cb2298cc2..eef15b374abb0 100644
--- a/arch/arm64/kvm/hyp/nvhe/host.S
+++ b/arch/arm64/kvm/hyp/nvhe/host.S
@@ -124,7 +124,7 @@ SYM_FUNC_START(__hyp_do_panic)
 	/* Ensure host stage-2 is disabled */
 	mrs	x0, hcr_el2
 	bic	x0, x0, #HCR_VM
-	msr	hcr_el2, x0
+	msr_hcr_el2 x0
 	isb
 	tlbi	vmalls12e1
 	dsb	nsh
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index f8af11189572f..aada42522e7be 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -100,7 +100,7 @@ SYM_CODE_START_LOCAL(___kvm_hyp_init)
 	msr	mair_el2, x1
 
 	ldr	x1, [x0, #NVHE_INIT_HCR_EL2]
-	msr	hcr_el2, x1
+	msr_hcr_el2 x1
 
 	mov	x2, #HCR_E2H
 	and	x2, x1, x2
@@ -262,7 +262,7 @@ reset:
 
 alternative_if ARM64_KVM_PROTECTED_MODE
 	mov_q	x5, HCR_HOST_NVHE_FLAGS
-	msr	hcr_el2, x5
+	msr_hcr_el2 x5
 alternative_else_nop_endif
 
 	/* Install stub vectors */
diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 31173c6946951..d1488d4e51413 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -309,7 +309,7 @@ int __pkvm_prot_finalize(void)
 	 */
 	kvm_flush_dcache_to_poc(params, sizeof(*params));
 
-	write_sysreg(params->hcr_el2, hcr_el2);
+	write_sysreg_hcr(params->hcr_el2);
 	__load_stage2(&host_mmu.arch.mmu, &host_mmu.arch);
 
 	/*
diff --git a/arch/arm64/kvm/hyp/nvhe/switch.c b/arch/arm64/kvm/hyp/nvhe/switch.c
index 7d2ba6ef02618..4024fafbe3594 100644
--- a/arch/arm64/kvm/hyp/nvhe/switch.c
+++ b/arch/arm64/kvm/hyp/nvhe/switch.c
@@ -142,7 +142,7 @@ static void __deactivate_traps(struct kvm_vcpu *vcpu)
 
 	__deactivate_traps_common(vcpu);
 
-	write_sysreg(this_cpu_ptr(&kvm_init_params)->hcr_el2, hcr_el2);
+	write_sysreg_hcr(this_cpu_ptr(&kvm_init_params)->hcr_el2);
 
 	__deactivate_cptr_traps(vcpu);
 	write_sysreg(__kvm_hyp_host_vector, vbar_el2);
diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c
index 50aa8dbcae75b..f8a91780e49a9 100644
--- a/arch/arm64/kvm/hyp/vgic-v3-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c
@@ -446,7 +446,7 @@ u64 __vgic_v3_get_gic_config(void)
 	if (has_vhe()) {
 		flags = local_daif_save();
 	} else {
-		sysreg_clear_set(hcr_el2, 0, HCR_AMO | HCR_FMO | HCR_IMO);
+		sysreg_clear_set_hcr(0, HCR_AMO | HCR_FMO | HCR_IMO);
 		isb();
 	}
 
@@ -461,7 +461,7 @@ u64 __vgic_v3_get_gic_config(void)
 	if (has_vhe()) {
 		local_daif_restore(flags);
 	} else {
-		sysreg_clear_set(hcr_el2, HCR_AMO | HCR_FMO | HCR_IMO, 0);
+		sysreg_clear_set_hcr(HCR_AMO | HCR_FMO | HCR_IMO, 0);
 		isb();
 	}
 
diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
index 731a0378ed132..faacdfb328af6 100644
--- a/arch/arm64/kvm/hyp/vhe/switch.c
+++ b/arch/arm64/kvm/hyp/vhe/switch.c
@@ -184,7 +184,7 @@ static void __deactivate_traps(struct kvm_vcpu *vcpu)
 
 	___deactivate_traps(vcpu);
 
-	write_sysreg(HCR_HOST_VHE_FLAGS, hcr_el2);
+	write_sysreg_hcr(HCR_HOST_VHE_FLAGS);
 
 	if (has_cntpoff()) {
 		struct timer_map map;
diff --git a/arch/arm64/kvm/hyp/vhe/tlb.c b/arch/arm64/kvm/hyp/vhe/tlb.c
index 3d50a1bd2bdbc..ec25698186297 100644
--- a/arch/arm64/kvm/hyp/vhe/tlb.c
+++ b/arch/arm64/kvm/hyp/vhe/tlb.c
@@ -63,7 +63,7 @@ static void enter_vmid_context(struct kvm_s2_mmu *mmu,
 	__load_stage2(mmu, mmu->arch);
 	val = read_sysreg(hcr_el2);
 	val &= ~HCR_TGE;
-	write_sysreg(val, hcr_el2);
+	write_sysreg_hcr(val);
 	isb();
 }
 
@@ -73,7 +73,7 @@ static void exit_vmid_context(struct tlb_inv_context *cxt)
 	 * We're done with the TLB operation, let's restore the host's
 	 * view of HCR_EL2.
 	 */
-	write_sysreg(HCR_HOST_VHE_FLAGS, hcr_el2);
+	write_sysreg_hcr(HCR_HOST_VHE_FLAGS);
 	isb();
 
 	/* ... and the stage-2 MMU context that we switched away from */
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index 772c1b008e437..72f10b74ce807 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -94,6 +94,7 @@ WORKAROUND_2457168
 WORKAROUND_2645198
 WORKAROUND_2658417
 WORKAROUND_AMPERE_AC03_CPU_38
+WORKAROUND_AMPERE_AC04_CPU_23
 WORKAROUND_TRBE_OVERWRITE_FILL_MODE
 WORKAROUND_TSB_FLUSH_FAILURE
 WORKAROUND_TRBE_WRITE_OUT_OF_RANGE
-- 
2.48.1

Re: [PATCH v4] arm64: errata: Work around AmpereOne's erratum AC04_CPU_23

[Catalin Marinas]

On Tue, May 13, 2025 at 11:45:14AM -0700, D Scott Phillips wrote:
> On AmpereOne AC04, updates to HCR_EL2 can rarely corrupt simultaneous
> translations for data addresses initiated by load/store instructions.
> Only instruction initiated translations are vulnerable, not translations
> from prefetches for example. A DSB before the store to HCR_EL2 is
> sufficient to prevent older instructions from hitting the window for
> corruption, and an ISB after is sufficient to prevent younger
> instructions from hitting the window for corruption.
> 
> Signed-off-by: D Scott Phillips <scott@os.amperecomputing.com>
> Reviewed-by: Oliver Upton <oliver.upton@linux.dev>

For the core arm64 bits:

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

Marc, Will - any preference on how this should go in (kvm or arm64
trees)?

Re: [PATCH v4] arm64: errata: Work around AmpereOne's erratum AC04_CPU_23

[Will Deacon]

On Mon, May 19, 2025 at 11:56:51AM +0100, Catalin Marinas wrote:
> On Tue, May 13, 2025 at 11:45:14AM -0700, D Scott Phillips wrote:
> > On AmpereOne AC04, updates to HCR_EL2 can rarely corrupt simultaneous
> > translations for data addresses initiated by load/store instructions.
> > Only instruction initiated translations are vulnerable, not translations
> > from prefetches for example. A DSB before the store to HCR_EL2 is
> > sufficient to prevent older instructions from hitting the window for
> > corruption, and an ISB after is sufficient to prevent younger
> > instructions from hitting the window for corruption.
> > 
> > Signed-off-by: D Scott Phillips <scott@os.amperecomputing.com>
> > Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
> 
> For the core arm64 bits:
> 
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> 
> Marc, Will - any preference on how this should go in (kvm or arm64
> trees)?

I think it makes most sense to go via the kvm tree based on the diffstat.

Cheers,

Will

Re: [PATCH v4] arm64: errata: Work around AmpereOne's erratum AC04_CPU_23

[Marc Zyngier]

On Tue, 13 May 2025 11:45:14 -0700, D Scott Phillips wrote:
> On AmpereOne AC04, updates to HCR_EL2 can rarely corrupt simultaneous
> translations for data addresses initiated by load/store instructions.
> Only instruction initiated translations are vulnerable, not translations
> from prefetches for example. A DSB before the store to HCR_EL2 is
> sufficient to prevent older instructions from hitting the window for
> corruption, and an ISB after is sufficient to prevent younger
> instructions from hitting the window for corruption.
> 
> [...]

Applied to next, thanks!

[1/1] arm64: errata: Work around AmpereOne's erratum AC04_CPU_23
      commit: fed55f49fad181be9dfb93c06efc4ab2b71a72a9

Cheers,

	M.
-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH v4] arm64: errata: Work around AmpereOne's erratum AC04_CPU_23

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

On Tue, May 13, 2025 at 11:45:14AM -0700, D Scott Phillips wrote:
> On AmpereOne AC04, updates to HCR_EL2 can rarely corrupt simultaneous
> translations for data addresses initiated by load/store instructions.
> Only instruction initiated translations are vulnerable, not translations
> from prefetches for example. A DSB before the store to HCR_EL2 is
> sufficient to prevent older instructions from hitting the window for
> corruption, and an ISB after is sufficient to prevent younger
> instructions from hitting the window for corruption.

This patch, which is in -next as fed55f49fad181be9dfb93c0, breaks the
build of at least the vDSO selftests:

$ make -C tools/testing/selftests ARCH=arm64 LLVM=1 TARGETS=vDSO

  CC       vdso_test_chacha
In file included from vgetrandom-chacha.S:9:
In file included from ./../../../../arch/arm64/kernel/vdso/vgetrandom-chacha.S:5:
In file included from /home/broonie/git/bisect/tools/testing/selftests/../../../arch/arm64/include/asm/assembler.h:21:
In file included from /home/broonie/git/bisect/tools/testing/selftests/../../../arch/arm64/include/asm/cpufeature.h:13:
/home/broonie/git/bisect/tools/testing/selftests/../../../arch/arm64/include/asm/sysreg.h:1097:5: error: function-like macro 'IS_ENABLED' is not defined
 1097 | #if IS_ENABLED(CONFIG_AMPERE_ERRATUM_AC04_CPU_23)
      |     ^
1 error generated.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v4] arm64: errata: Work around AmpereOne's erratum AC04_CPU_23

[Marc Zyngier]

On Fri, 23 May 2025 15:15:53 +0100,
Mark Brown <broonie@kernel.org> wrote:
> 
> On Tue, May 13, 2025 at 11:45:14AM -0700, D Scott Phillips wrote:
> > On AmpereOne AC04, updates to HCR_EL2 can rarely corrupt simultaneous
> > translations for data addresses initiated by load/store instructions.
> > Only instruction initiated translations are vulnerable, not translations
> > from prefetches for example. A DSB before the store to HCR_EL2 is
> > sufficient to prevent older instructions from hitting the window for
> > corruption, and an ISB after is sufficient to prevent younger
> > instructions from hitting the window for corruption.
> 
> This patch, which is in -next as fed55f49fad181be9dfb93c0, breaks the
> build of at least the vDSO selftests:
> 
> $ make -C tools/testing/selftests ARCH=arm64 LLVM=1 TARGETS=vDSO
> 
>   CC       vdso_test_chacha
> In file included from vgetrandom-chacha.S:9:
> In file included from ./../../../../arch/arm64/kernel/vdso/vgetrandom-chacha.S:5:
> In file included from /home/broonie/git/bisect/tools/testing/selftests/../../../arch/arm64/include/asm/assembler.h:21:
> In file included from /home/broonie/git/bisect/tools/testing/selftests/../../../arch/arm64/include/asm/cpufeature.h:13:
> /home/broonie/git/bisect/tools/testing/selftests/../../../arch/arm64/include/asm/sysreg.h:1097:5: error: function-like macro 'IS_ENABLED' is not defined
>  1097 | #if IS_ENABLED(CONFIG_AMPERE_ERRATUM_AC04_CPU_23)
>       |     ^
> 1 error generated.

This:

diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index ad63457a05c5b..4389d3916426c 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -13,6 +13,7 @@
 #define __ASM_ASSEMBLER_H
 
 #include <linux/export.h>
+#include <linux/kconfig.h>
 
 #include <asm/alternative.h>
 #include <asm/asm-bug.h>

should solve it.

But it also outlines that the vdso is getting built using stuff that
is not meant for userspace code.

	M.

-- 
Jazz isn't dead. It just smells funny.

Re: [PATCH v4] arm64: errata: Work around AmpereOne's erratum AC04_CPU_23

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]

On Fri, May 23, 2025 at 04:00:06PM +0100, Marc Zyngier wrote:
> On Fri, 23 May 2025 15:15:53 +0100,
> Mark Brown <broonie@kernel.org> wrote:
> > On Tue, May 13, 2025 at 11:45:14AM -0700, D Scott Phillips wrote:

> > > On AmpereOne AC04, updates to HCR_EL2 can rarely corrupt simultaneous
> > > translations for data addresses initiated by load/store instructions.

> > This patch, which is in -next as fed55f49fad181be9dfb93c0, breaks the
> > build of at least the vDSO selftests:

> > $ make -C tools/testing/selftests ARCH=arm64 LLVM=1 TARGETS=vDSO

> >   CC       vdso_test_chacha
> > In file included from vgetrandom-chacha.S:9:
> > In file included from ./../../../../arch/arm64/kernel/vdso/vgetrandom-chacha.S:5:
> > In file included from /home/broonie/git/bisect/tools/testing/selftests/../../../arch/arm64/include/asm/assembler.h:21:
> > In file included from /home/broonie/git/bisect/tools/testing/selftests/../../../arch/arm64/include/asm/cpufeature.h:13:
> > /home/broonie/git/bisect/tools/testing/selftests/../../../arch/arm64/include/asm/sysreg.h:1097:5: error: function-like macro 'IS_ENABLED' is not defined
> >  1097 | #if IS_ENABLED(CONFIG_AMPERE_ERRATUM_AC04_CPU_23)
> >       |     ^
> > 1 error generated.

> This:

...

> should solve it.

Yes, that works.

Tested-by: Mark Brown <broonie@kernel.org>

> But it also outlines that the vdso is getting built using stuff that
> is not meant for userspace code.

Indeed, adding Jason for that.  It's the same for all architectures.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v4] arm64: errata: Work around AmpereOne's erratum AC04_CPU_23

[Jaikiran Pai]

Hello Scott,

On 14/05/25 12:15 am, D Scott Phillips wrote:
> On AmpereOne AC04, updates to HCR_EL2 can rarely corrupt simultaneous
> translations for data addresses initiated by load/store instructions.
> Only instruction initiated translations are vulnerable, not translations
> from prefetches for example. A DSB before the store to HCR_EL2 is
> sufficient to prevent older instructions from hitting the window for
> corruption, and an ISB after is sufficient to prevent younger
> instructions from hitting the window for corruption.

I see that this patch enables the workaround only for AmpereOne AC04 
systems. Do you happen to know if the underlying issue for which this 
patch was introduced, impacts (or can impact) AmpereOne AC03 systems too:

CPU implementer    : 0xc0
CPU architecture: 8
CPU variant    : 0x0
CPU part    : 0xac3
CPU revision    : 1

-Jaikiran

Re: [PATCH v4] arm64: errata: Work around AmpereOne's erratum AC04_CPU_23

[D Scott Phillips]

Jaikiran Pai <jai.forums2013@gmail.com> writes:

> Hello Scott,
>
> On 14/05/25 12:15 am, D Scott Phillips wrote:
>> On AmpereOne AC04, updates to HCR_EL2 can rarely corrupt simultaneous
>> translations for data addresses initiated by load/store instructions.
>> Only instruction initiated translations are vulnerable, not translations
>> from prefetches for example. A DSB before the store to HCR_EL2 is
>> sufficient to prevent older instructions from hitting the window for
>> corruption, and an ISB after is sufficient to prevent younger
>> instructions from hitting the window for corruption.
>
> I see that this patch enables the workaround only for AmpereOne AC04 
> systems. Do you happen to know if the underlying issue for which this 
> patch was introduced, impacts (or can impact) AmpereOne AC03 systems too:

Hi Jaikiran, this issue impacts ac04 only, it is not present on ac03.

Re: [PATCH v4] arm64: errata: Work around AmpereOne's erratum AC04_CPU_23

[Jaikiran Pai]

On 17/11/25 10:47 pm, D Scott Phillips wrote:
> Jaikiran Pai <jai.forums2013@gmail.com> writes:
>
>> Hello Scott,
>>
>> On 14/05/25 12:15 am, D Scott Phillips wrote:
>>> On AmpereOne AC04, updates to HCR_EL2 can rarely corrupt simultaneous
>>> translations for data addresses initiated by load/store instructions.
>>> Only instruction initiated translations are vulnerable, not translations
>>> from prefetches for example. A DSB before the store to HCR_EL2 is
>>> sufficient to prevent older instructions from hitting the window for
>>> corruption, and an ISB after is sufficient to prevent younger
>>> instructions from hitting the window for corruption.
>> I see that this patch enables the workaround only for AmpereOne AC04
>> systems. Do you happen to know if the underlying issue for which this
>> patch was introduced, impacts (or can impact) AmpereOne AC03 systems too:
> Hi Jaikiran, this issue impacts ac04 only, it is not present on ac03.


Thank you Scott for the quick confirmation.

We have been investigating an issue on AC03 (running Oracle Linux as a 
VM) where some memory writes (stores) are lost especially when the OS 
appears to have accumulated high buf/cache usage (monitored through free 
-h). That investigation, backed by a trivial C reproducer, is still 
ongoing and we are trying to understand what could be causing it. The 
issue description here made us curious whether it's the same issue we 
are running into and since this patch wasn't applied on AC03, we decided 
to check once.

While at it, if you have any inputs (tools/commands) that you typically 
use to narrow down such issues, I would be happy to experiment with if 
feasible. Right now we are focusing on the kernel itself and checking 
which specific kernel versions can reproduce it. We have been able to 
reproduce it consistently on 5.15.x and 5.16.x and we plan to try it 
with other kernel versions all the way upto 6.12. That should tell us if 
the issue we are encountering has already been addressed in any specific 
kernel version.

Given that you noted this patch isn't relevant for AC03, I don't plan to 
further reply-all to this PATCH discussion, but if you would like me to 
keep you updated with this investigation (I would love to get some 
inputs and provide updates as we go along) then please let me know and I 
will communicate with you over your email (or any other relevant forum 
you suggest).

Thank you again for the quick response.

-Jaikiran