[PATCH v2 0/4] arm64: Add workarounds for FUJITSU-MONAKA CPU

[PATCH v2 0/4] arm64: Add workarounds for FUJITSU-MONAKA CPU

[Tomohiro Misono]

Changes in v2:
 - Address review comments in patch 2-4. See each commits for the details
 - rebased on 7.3-rc7
 - Link to v1: https://lore.kernel.org/r/20261002-monaka-fix-for-upstream-v1-0-4aec0b0cbe34@fujitsu.com

This series adds three workarounds for the FUJITSU-MONAKA CPU.
 - Patch 1 ... Add the FUJITSU-MONAKA CPU type definition
 - Patch 2 ... Add a workaround for TLBI operation on 64k page size
 - Patch 3 ... Add a workaround for perf operation
 - Patch 4 ... Add a workaround for GIC operation

Although the three workarounds do not depend on each other functionally,
I have combined them into one series because patch 2-4
use the CPU type definition added by the first patch,
and all the workarounds update silicon-errata.rst.

If preferred, I will resend them as separate patches.

This series is based on v7.3-rc7.

Best Regards,
Tomohiro Misono

Signed-off-by: Tomohiro Misono <misono.tomohiro@fujitsu.com>
---
Kohei Enju (1):
      irqchip/gicv3: Add workaround for FUJITSU-MONAKA erratum E#030003

Tomohiro Misono (3):
      arm64: cputype: Add FUJITSU MONAKA definition
      arm64: tlb: Add tlbi workaround for FUJITSU-MONAKA Erratum E#030001
      perf: arm_pmu: Add workaround for FUJITSU-MONAKA Erratum E#030002

 Documentation/arch/arm64/silicon-errata.rst |  6 ++++
 arch/arm64/Kconfig                          | 36 +++++++++++++++++++++++
 arch/arm64/include/asm/cpucaps.h            |  4 +++
 arch/arm64/include/asm/cputype.h            |  2 ++
 arch/arm64/include/asm/tlbflush.h           | 35 +++++++++++++++++++++++
 arch/arm64/kernel/cpu_errata.c              | 20 +++++++++++++
 arch/arm64/kvm/hyp/vhe/tlb.c                | 44 +++++++++++++++++++++++++++++
 arch/arm64/tools/cpucaps                    |  2 ++
 drivers/irqchip/irq-gic-v3.c                | 32 +++++++++++++++++++++
 drivers/perf/arm_pmu.c                      | 13 +++++++++
 10 files changed, 194 insertions(+)
---
base-commit: 24a19b953e2a3d0ea5a8c4951a0ab8f32720c907
change-id: 20261002-monaka-fix-for-upstream-680801dea92f

Best regards,
-- 
Tomohiro Misono <misono.tomohiro@fujitsu.com>

[PATCH v2 1/4] arm64: cputype: Add FUJITSU MONAKA definition

[Tomohiro Misono]

Add cpu part definition for FUJITSU-MONAKA.

Signed-off-by: Tomohiro Misono <misono.tomohiro@fujitsu.com>
---
 arch/arm64/include/asm/cputype.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 1fa29616e586e..3f648cb10e61c 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -138,6 +138,7 @@
 #define NVIDIA_CPU_PART_OLYMPUS		0x010
 
 #define FUJITSU_CPU_PART_A64FX		0x001
+#define FUJITSU_CPU_PART_MONAKA		0x003
 
 #define HISI_CPU_PART_TSV110		0xD01
 #define HISI_CPU_PART_HIP09			0xD02
@@ -235,6 +236,7 @@
 #define MIDR_NVIDIA_CARMEL MIDR_CPU_MODEL(ARM_CPU_IMP_NVIDIA, NVIDIA_CPU_PART_CARMEL)
 #define MIDR_NVIDIA_OLYMPUS MIDR_CPU_MODEL(ARM_CPU_IMP_NVIDIA, NVIDIA_CPU_PART_OLYMPUS)
 #define MIDR_FUJITSU_A64FX MIDR_CPU_MODEL(ARM_CPU_IMP_FUJITSU, FUJITSU_CPU_PART_A64FX)
+#define MIDR_FUJITSU_MONAKA MIDR_CPU_MODEL(ARM_CPU_IMP_FUJITSU, FUJITSU_CPU_PART_MONAKA)
 #define MIDR_HISI_TSV110 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_TSV110)
 #define MIDR_HISI_HIP09 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_HIP09)
 #define MIDR_HISI_HIP12 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_HIP12)

-- 
2.43.0

Re: [PATCH v2 1/4] arm64: cputype: Add FUJITSU MONAKA definition

[sashiko-bot]

> Add cpu part definition for FUJITSU-MONAKA.
> 
> Signed-off-by: Tomohiro Misono <misono.tomohiro@fujitsu.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016-monaka-fix-for-upstream-v2-0-fc7ede7f9f48@fujitsu.com?part=1

Re: [PATCH v2 1/4] arm64: cputype: Add FUJITSU MONAKA definition

[Mark Rutland]

On Fri, Oct 16, 2026 at 07:00:45PM +0900, Tomohiro Misono wrote:
> Add cpu part definition for FUJITSU-MONAKA.
> 
> Signed-off-by: Tomohiro Misono <misono.tomohiro@fujitsu.com>

FWIW, this looks fine, so:

Acked-by: Mark Rutland <mark.rutland@arm.com>

I assume that Will and Catalin pick up along with the other patches,
when folk are happy they're all ready.

Mark.

> ---
>  arch/arm64/include/asm/cputype.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
> index 1fa29616e586e..3f648cb10e61c 100644
> --- a/arch/arm64/include/asm/cputype.h
> +++ b/arch/arm64/include/asm/cputype.h
> @@ -138,6 +138,7 @@
>  #define NVIDIA_CPU_PART_OLYMPUS		0x010
>  
>  #define FUJITSU_CPU_PART_A64FX		0x001
> +#define FUJITSU_CPU_PART_MONAKA		0x003
>  
>  #define HISI_CPU_PART_TSV110		0xD01
>  #define HISI_CPU_PART_HIP09			0xD02
> @@ -235,6 +236,7 @@
>  #define MIDR_NVIDIA_CARMEL MIDR_CPU_MODEL(ARM_CPU_IMP_NVIDIA, NVIDIA_CPU_PART_CARMEL)
>  #define MIDR_NVIDIA_OLYMPUS MIDR_CPU_MODEL(ARM_CPU_IMP_NVIDIA, NVIDIA_CPU_PART_OLYMPUS)
>  #define MIDR_FUJITSU_A64FX MIDR_CPU_MODEL(ARM_CPU_IMP_FUJITSU, FUJITSU_CPU_PART_A64FX)
> +#define MIDR_FUJITSU_MONAKA MIDR_CPU_MODEL(ARM_CPU_IMP_FUJITSU, FUJITSU_CPU_PART_MONAKA)
>  #define MIDR_HISI_TSV110 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_TSV110)
>  #define MIDR_HISI_HIP09 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_HIP09)
>  #define MIDR_HISI_HIP12 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_HIP12)
> 
> -- 
> 2.43.0
> 

[PATCH v2 2/4] arm64: tlb: Add tlbi workaround for FUJITSU-MONAKA Erratum E#030001

[Tomohiro Misono]

FUJITSU-MONAKA Erratum E#030001 affects FUJITSU-MONAKA CPU
when using TLBI range operations.

On affected FUJITSU-MONAKA CPUs, range-based TLBI operations
targeting a VA or IPA may fail to invalidate TLB entries when
addr[34:29] == all 1 && addr[28:0] == 0 for 512MB mappings.
The affected instructions are:
  RVA[L]E{1,2,3}*, RVAA[L]E1*, and RIPAS2[L]E1*.

Work around the erratum by issuing additional non-range
TLBI instructions corresponding to the affected VA or IPA
range-based TLBI operations.

Signed-off-by: Tomohiro Misono <misono.tomohiro@fujitsu.com>

---
Changes in v2:
 - remove page size restrictions as this errata affects both S1 and S2 tables
 - use __always_inline instead of inline
 - call workaround from NV TLBI operations too (comment by sashiko)
  - TODO: test using NV
---
---
 Documentation/arch/arm64/silicon-errata.rst |  2 ++
 arch/arm64/Kconfig                          | 19 +++++++++++++
 arch/arm64/include/asm/cpucaps.h            |  2 ++
 arch/arm64/include/asm/tlbflush.h           | 35 +++++++++++++++++++++++
 arch/arm64/kernel/cpu_errata.c              | 10 +++++++
 arch/arm64/kvm/hyp/vhe/tlb.c                | 44 +++++++++++++++++++++++++++++
 arch/arm64/tools/cpucaps                    |  1 +
 7 files changed, 113 insertions(+)

diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
index 99a1eb4b833dd..527af20b26468 100644
--- a/Documentation/arch/arm64/silicon-errata.rst
+++ b/Documentation/arch/arm64/silicon-errata.rst
@@ -375,6 +375,8 @@ stable kernels.
 +----------------+-----------------+-----------------+-----------------------------+
 | Fujitsu        | A64FX           | E#010001        | FUJITSU_ERRATUM_010001      |
 +----------------+-----------------+-----------------+-----------------------------+
+| Fujitsu        | MONAKA          | E#030001        | FUJITSU_ERRATUM_030001      |
++----------------+-----------------+-----------------+-----------------------------+
 +----------------+-----------------+-----------------+-----------------------------+
 | ASR            | ASR8601         | #8601001        | N/A                         |
 +----------------+-----------------+-----------------+-----------------------------+
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index cab741a695f52..5d1a17ab0f593 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1342,6 +1342,25 @@ config FUJITSU_ERRATUM_010001
 
 	  If unsure, say Y.
 
+config FUJITSU_ERRATUM_030001
+	bool "FUJITSU-MONAKA erratum E#030001: Range TLBI may fail to invalidate some entries"
+	default y
+	help
+	  This option adds a workaround for FUJITSU-MONAKA erratum E#030001.
+	  On affected FUJITSU-MONAKA CPUs, range-based TLBI operation
+	  targeting a VA or IPA may fail to invalidate some TLB entries
+	  when hugepage is used in a certain condition. The affected
+	  instructions are RVA[L]E{1,2,3}*, RVAA[L]E1*, and RIPAS2[L]E1*
+	  and this affects on both S1 and S2 tables.
+
+	  Work around the erratum by issuing additional non-range TLBI
+	  instructions corresponding to the affected VA or IPA range-based
+	  TLBI operations.
+
+	  The erratum only affects the FUJITSU-MONAKA.
+
+	  If unsure, say Y.
+
 config HISILICON_ERRATUM_161600802
 	bool "Hip07 161600802: Erroneous redistributor VLPI base"
 	default y
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 76350b38f0d7a..9220b917ec207 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -66,6 +66,8 @@ cpucap_is_possible(const unsigned int cap)
 		return IS_ENABLED(CONFIG_ARM64_ERRATUM_3194386);
 	case ARM64_WORKAROUND_4193714:
 		return IS_ENABLED(CONFIG_ARM64_ERRATUM_4193714);
+	case ARM64_WORKAROUND_FUJITSU_030001:
+		return IS_ENABLED(CONFIG_FUJITSU_ERRATUM_030001);
 	case ARM64_MPAM:
 		/*
 		 * KVM MPAM support doesn't rely on the host kernel supporting MPAM.
diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
index 14a78ac0f8009..2636c273b8111 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -487,6 +487,39 @@ static __always_inline void __tlbi_range(tlbi_op op, u64 addr,
 	op(arg);
 }
 
+#ifdef CONFIG_FUJITSU_ERRATUM_030001
+static __always_inline void fujitsu_erratum_wa(tlbi_op lop, u64 start, u64 end, u16 asid)
+{
+	u64 addr;
+
+	if (!alternative_has_cap_unlikely(ARM64_WORKAROUND_FUJITSU_030001))
+		return;
+
+	/*
+	 * The erratum fails to invalidate TLBI entries in the range when
+	 * addr[34:29] == all 1 && addr[28:0] == all 0 for 512M hugepage.
+	 * This affects both on S1 and S2 tables and 4k guest may be affected
+	 * if host uses 64k page size. Therefore it cannot be determined
+	 * reliably if the target entry is affected or not here. So, always
+	 * assume hugepage is used.
+	 * The workaround is to issue extra non-range TLBI ops corresponding
+	 * to the affected VA or IPA range-based ops in the range.
+	 */
+	addr = (start & GENMASK_ULL(63, 35)) | GENMASK_ULL(34, 29);
+	while (addr < end) {
+		__tlbi_level_asid(lop, addr, TLBI_TTL_UNKNOWN, asid);
+		if (addr + BIT_ULL(35) < addr)
+			/* overflow */
+			break;
+		addr += BIT_ULL(35);
+	}
+}
+#else
+static __always_inline void fujitsu_erratum_wa(tlbi_op lop, u64 start, u64 end, u16 asid)
+{
+}
+#endif /* CONFIG_FUJITSU_ERRATUM_030001 */
+
 static __always_inline void __flush_tlb_range_op(tlbi_op lop, tlbi_op rop,
 						 u64 start, size_t pages,
 						 u64 stride, u16 asid,
@@ -518,6 +551,8 @@ static __always_inline void __flush_tlb_range_op(tlbi_op lop, tlbi_op rop,
 		__tlbi_level_asid(lop, addr, level, asid);
 		addr += stride;
 	}
+
+	fujitsu_erratum_wa(lop, start, end, asid);
 }
 
 #define __flush_s1_tlb_range_op(op, start, pages, stride, asid, tlb_level) \
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index e0c09402540ce..a11135f83e858 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -1039,6 +1039,16 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
 		.matches = has_impdef_pmuv3,
 		.cpu_enable = cpu_enable_impdef_pmuv3_traps,
 	},
+#ifdef CONFIG_FUJITSU_ERRATUM_030001
+	{
+		.desc = "FUJITSU-MONAKA Erratum E#030001",
+		.capability = ARM64_WORKAROUND_FUJITSU_030001,
+		ERRATA_MIDR_RANGE_LIST(((const struct midr_range[]) {
+					MIDR_ALL_VERSIONS(MIDR_FUJITSU_MONAKA),
+					{}
+				})),
+	},
+#endif
 	{
 		.desc = "Known broken GICv3 SEIS implementation",
 		.capability = ARM64_WORKAROUND_GICv3_BROKEN_SEIS,
diff --git a/arch/arm64/kvm/hyp/vhe/tlb.c b/arch/arm64/kvm/hyp/vhe/tlb.c
index c386d9f1c1016..2f1a7fab5eb97 100644
--- a/arch/arm64/kvm/hyp/vhe/tlb.c
+++ b/arch/arm64/kvm/hyp/vhe/tlb.c
@@ -8,6 +8,7 @@
 
 #include <asm/kvm_hyp.h>
 #include <asm/kvm_mmu.h>
+#include <asm/kvm_nested.h>
 #include <asm/tlbflush.h>
 
 struct tlb_inv_context {
@@ -218,6 +219,45 @@ void __kvm_flush_vm_context(void)
 	__tlbi_sync_s1ish_hyp();
 }
 
+#ifdef CONFIG_FUJITSU_ERRATUM_030001
+static __always_inline void __vae1is(u64 arg)
+{
+	__tlbi(vae1is, arg);
+}
+static __always_inline void __vale1is(u64 arg)
+{
+	__tlbi(vale1is, arg);
+}
+static __always_inline void __vaae1is(u64 arg)
+{
+	__tlbi(vaae1is, arg);
+}
+static __always_inline void __fujitsu_erratum_wa(tlbi_op op, u64 va)
+{
+	u64 start, size;
+	u16 asid;
+
+	if (!alternative_has_cap_unlikely(ARM64_WORKAROUND_FUJITSU_030001))
+		return;
+
+	start = decode_range_tlbi(va, &size, &asid);
+	fujitsu_erratum_wa(op, start, start + size, asid);
+}
+#else
+static __always_inline void __vae1is(u64 arg)
+{
+}
+static __always_inline void __vale1is(u64 arg)
+{
+}
+static __always_inline void __vaae1is(u64 arg)
+{
+}
+static __always_inline void __fujitsu_erratum_wa(tlbi_op op, u64 va)
+{
+}
+#endif
+
 /*
  * TLB invalidation emulation for NV. For any given instruction, we
  * perform the following transformtions:
@@ -322,6 +362,7 @@ int __kvm_tlbi_s1e2(struct kvm_s2_mmu *mmu, u64 va, u64 sys_encoding)
 	case OP_TLBI_RVAE1ISNXS:
 	case OP_TLBI_RVAE1OSNXS:
 		__tlbi(rvae1is, va);
+		__fujitsu_erratum_wa(__vae1is, va);
 		break;
 	case OP_TLBI_RVALE2:
 	case OP_TLBI_RVALE2IS:
@@ -336,6 +377,7 @@ int __kvm_tlbi_s1e2(struct kvm_s2_mmu *mmu, u64 va, u64 sys_encoding)
 	case OP_TLBI_RVALE1ISNXS:
 	case OP_TLBI_RVALE1OSNXS:
 		__tlbi(rvale1is, va);
+		__fujitsu_erratum_wa(__vale1is, va);
 		break;
 	case OP_TLBI_RVAAE1:
 	case OP_TLBI_RVAAE1IS:
@@ -344,6 +386,7 @@ int __kvm_tlbi_s1e2(struct kvm_s2_mmu *mmu, u64 va, u64 sys_encoding)
 	case OP_TLBI_RVAAE1ISNXS:
 	case OP_TLBI_RVAAE1OSNXS:
 		__tlbi(rvaae1is, va);
+		__fujitsu_erratum_wa(__vaae1is, va);
 		break;
 	case OP_TLBI_RVAALE1:
 	case OP_TLBI_RVAALE1IS:
@@ -352,6 +395,7 @@ int __kvm_tlbi_s1e2(struct kvm_s2_mmu *mmu, u64 va, u64 sys_encoding)
 	case OP_TLBI_RVAALE1ISNXS:
 	case OP_TLBI_RVAALE1OSNXS:
 		__tlbi(rvaale1is, va);
+		__fujitsu_erratum_wa(vaale1is, va);
 		break;
 	default:
 		ret = -EINVAL;
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index 58b6c084f9f25..1e57a0105395b 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -132,3 +132,4 @@ WORKAROUND_SPECULATIVE_AT
 WORKAROUND_SPECULATIVE_SSBS
 WORKAROUND_SPECULATIVE_UNPRIV_LOAD
 WORKAROUND_BROKEN_AMU_CONSTCNT
+WORKAROUND_FUJITSU_030001

-- 
2.43.0

Re: [PATCH v2 2/4] arm64: tlb: Add tlbi workaround for FUJITSU-MONAKA Erratum E#030001

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] kvm: arm64: erratum workaround injects host translation granule into guest TLBI
- [Medium] kvm: arm64: erratum workaround loop bypassed on address space wrap-around
--

commit bd446dc250f0ed99bcd777fad354a7212578bba8
Author: Tomohiro Misono <misono.tomohiro@fujitsu.com>

arm64: tlb: Add tlbi workaround for FUJITSU-MONAKA Erratum E#030001

This commit adds a workaround for FUJITSU-MONAKA Erratum E#030001, where
range-based TLBI operations targeting a VA or IPA may fail to invalidate
TLB entries for 512MB mappings. It works around the erratum by issuing
additional non-range TLBI instructions corresponding to the affected VA or
IPA range-based TLBI operations.

> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
> index 14a78ac0f8009..2636c273b8111 100644
> --- a/arch/arm64/include/asm/tlbflush.h
> +++ b/arch/arm64/include/asm/tlbflush.h

[ ... ]

> @@ -487,6 +487,39 @@ static __always_inline void __tlbi_range(tlbi_op op, u64 addr,
>  	op(arg);
>  }
>  
> +#ifdef CONFIG_FUJITSU_ERRATUM_030001
> +static __always_inline void fujitsu_erratum_wa(tlbi_op lop, u64 start, u64 end, u16 asid)
> +{
> +	u64 addr;
> +
> +	if (!alternative_has_cap_unlikely(ARM64_WORKAROUND_FUJITSU_030001))
> +		return;
> +
> +	/*
> +	 * The erratum fails to invalidate TLBI entries in the range when
> +	 * addr[34:29] == all 1 && addr[28:0] == all 0 for 512M hugepage.
> +	 * This affects both on S1 and S2 tables and 4k guest may be affected
> +	 * if host uses 64k page size. Therefore it cannot be determined
> +	 * reliably if the target entry is affected or not here. So, always
> +	 * assume hugepage is used.
> +	 * The workaround is to issue extra non-range TLBI ops corresponding
> +	 * to the affected VA or IPA range-based ops in the range.
> +	 */
> +	addr = (start & GENMASK_ULL(63, 35)) | GENMASK_ULL(34, 29);
> +	while (addr < end) {
> +		__tlbi_level_asid(lop, addr, TLBI_TTL_UNKNOWN, asid);

[Severity: High]
Can this inject the host's translation granule into a guest TLBI?

When KVM handles a nested guest's range TLB invalidation, it calls
__fujitsu_erratum_wa(), which invokes this fujitsu_erratum_wa() helper. The
loop here calls __tlbi_level_asid(lop, addr, TLBI_TTL_UNKNOWN, asid).

Looking at __tlbi_level_asid():

static __always_inline void __tlbi_level_asid(tlbi_op op, u64 addr, u32 level,
                                              u16 asid)
{
        ...
        if (alternative_has_cap_unlikely(ARM64_HAS_ARMv8_4_TTL) && level <= 3) {
                u64 ttl = level | (get_trans_granule() << 2);
                FIELD_MODIFY(TLBI_TTL_MASK, &arg, ttl);
        }
        op(arg);
}

Since TLBI_TTL_UNKNOWN is 0 and 0 <= 3, __tlbi_level_asid() unconditionally
sets the TTL field using get_trans_granule(). However, get_trans_granule()
returns the host kernel's compile-time page size. If the guest is operating
with a different translation granule (e.g., 4K pages in the guest while the
host is configured for 64K), the invalidation is issued with a mismatched TG
hint.

According to the ARM Architecture Reference Manual, a TLBI with a TTL field
that does not match the actual translation regime's granule may fail to
invalidate any entries. Does this leave stale TLB entries in the guest
context?

> +		if (addr + BIT_ULL(35) < addr)
> +			/* overflow */
> +			break;
> +		addr += BIT_ULL(35);
> +	}
> +}

[ ... ]

> diff --git a/arch/arm64/kvm/hyp/vhe/tlb.c b/arch/arm64/kvm/hyp/vhe/tlb.c
> index c386d9f1c1016..2f1a7fab5eb97 100644
> --- a/arch/arm64/kvm/hyp/vhe/tlb.c
> +++ b/arch/arm64/kvm/hyp/vhe/tlb.c

[ ... ]

> @@ -218,6 +219,45 @@ void __kvm_flush_vm_context(void)
>  	__tlbi_sync_s1ish_hyp();
>  }
>  
> +#ifdef CONFIG_FUJITSU_ERRATUM_030001
> +static __always_inline void __vae1is(u64 arg)
> +{
> +	__tlbi(vae1is, arg);
> +}
> +static __always_inline void __vale1is(u64 arg)
> +{
> +	__tlbi(vale1is, arg);
> +}
> +static __always_inline void __vaae1is(u64 arg)
> +{
> +	__tlbi(vaae1is, arg);
> +}
> +static __always_inline void __fujitsu_erratum_wa(tlbi_op op, u64 va)
> +{
> +	u64 start, size;
> +	u16 asid;
> +
> +	if (!alternative_has_cap_unlikely(ARM64_WORKAROUND_FUJITSU_030001))
> +		return;
> +
> +	start = decode_range_tlbi(va, &size, &asid);
> +	fujitsu_erratum_wa(op, start, start + size, asid);

[Severity: Medium]
Does this bypass the erratum workaround if the address space wraps around?

When KVM emulates a guest range TLBI instruction, it decodes the range via
decode_range_tlbi(). If the guest specifies a range that spans to the very end
of the 64-bit address space, decode_range_tlbi() caps size such that
start + size exactly overflows to 0.

Passing start + size as the end argument makes end = 0. Inside
fujitsu_erratum_wa(), the workaround loop uses the condition:

while (addr < end) {
        ...
}

Because addr is an unsigned 64-bit integer pointing to the upper half of the
address space, addr < 0 immediately evaluates to false, skipping the
workaround entirely.

> +}
> +#else
> +static __always_inline void __vae1is(u64 arg)
> +{
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016-monaka-fix-for-upstream-v2-0-fc7ede7f9f48@fujitsu.com?part=2

Re: [PATCH v2 2/4] arm64: tlb: Add tlbi workaround for FUJITSU-MONAKA Erratum E#030001

[Mark Rutland]

On Fri, Oct 16, 2026 at 07:00:46PM +0900, Tomohiro Misono wrote:
> FUJITSU-MONAKA Erratum E#030001 affects FUJITSU-MONAKA CPU
> when using TLBI range operations.
> 
> On affected FUJITSU-MONAKA CPUs, range-based TLBI operations
> targeting a VA or IPA may fail to invalidate TLB entries when
> addr[34:29] == all 1 && addr[28:0] == 0 for 512MB mappings.
> The affected instructions are:
>   RVA[L]E{1,2,3}*, RVAA[L]E1*, and RIPAS2[L]E1*.
> 
> Work around the erratum by issuing additional non-range
> TLBI instructions corresponding to the affected VA or IPA
> range-based TLBI operations.
> 
> Signed-off-by: Tomohiro Misono <misono.tomohiro@fujitsu.com>

As Will and I suggested last time, we'd prefer to disable range
operations on these parts (and ensure that the relevant ID field is
hidden from KVM guests).

Regardless of whether eventually accept the approach you propose here,
we first need something simple to backport to stable trees (as I assume
you'll want to run standard Linux distributions on this hardware). The
TLB invalidation code has changed a lot over time, and I don't think
it's practical or sensible to backport this patch.

As a first step, I think we should simply disable the use of range
operations on these parts, and ensure that KVM hides the relevant ID
field. After that, we can consider optimizing the workaround, as you
propose here.

Marc, does that align with your expectations? Is there an existing
pattern to follow for hiding the ID field?

Mark.

> 
> ---
> Changes in v2:
>  - remove page size restrictions as this errata affects both S1 and S2 tables
>  - use __always_inline instead of inline
>  - call workaround from NV TLBI operations too (comment by sashiko)
>   - TODO: test using NV
> ---
> ---
>  Documentation/arch/arm64/silicon-errata.rst |  2 ++
>  arch/arm64/Kconfig                          | 19 +++++++++++++
>  arch/arm64/include/asm/cpucaps.h            |  2 ++
>  arch/arm64/include/asm/tlbflush.h           | 35 +++++++++++++++++++++++
>  arch/arm64/kernel/cpu_errata.c              | 10 +++++++
>  arch/arm64/kvm/hyp/vhe/tlb.c                | 44 +++++++++++++++++++++++++++++
>  arch/arm64/tools/cpucaps                    |  1 +
>  7 files changed, 113 insertions(+)
> 
> diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
> index 99a1eb4b833dd..527af20b26468 100644
> --- a/Documentation/arch/arm64/silicon-errata.rst
> +++ b/Documentation/arch/arm64/silicon-errata.rst
> @@ -375,6 +375,8 @@ stable kernels.
>  +----------------+-----------------+-----------------+-----------------------------+
>  | Fujitsu        | A64FX           | E#010001        | FUJITSU_ERRATUM_010001      |
>  +----------------+-----------------+-----------------+-----------------------------+
> +| Fujitsu        | MONAKA          | E#030001        | FUJITSU_ERRATUM_030001      |
> ++----------------+-----------------+-----------------+-----------------------------+
>  +----------------+-----------------+-----------------+-----------------------------+
>  | ASR            | ASR8601         | #8601001        | N/A                         |
>  +----------------+-----------------+-----------------+-----------------------------+
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index cab741a695f52..5d1a17ab0f593 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1342,6 +1342,25 @@ config FUJITSU_ERRATUM_010001
>  
>  	  If unsure, say Y.
>  
> +config FUJITSU_ERRATUM_030001
> +	bool "FUJITSU-MONAKA erratum E#030001: Range TLBI may fail to invalidate some entries"
> +	default y
> +	help
> +	  This option adds a workaround for FUJITSU-MONAKA erratum E#030001.
> +	  On affected FUJITSU-MONAKA CPUs, range-based TLBI operation
> +	  targeting a VA or IPA may fail to invalidate some TLB entries
> +	  when hugepage is used in a certain condition. The affected
> +	  instructions are RVA[L]E{1,2,3}*, RVAA[L]E1*, and RIPAS2[L]E1*
> +	  and this affects on both S1 and S2 tables.
> +
> +	  Work around the erratum by issuing additional non-range TLBI
> +	  instructions corresponding to the affected VA or IPA range-based
> +	  TLBI operations.
> +
> +	  The erratum only affects the FUJITSU-MONAKA.
> +
> +	  If unsure, say Y.
> +
>  config HISILICON_ERRATUM_161600802
>  	bool "Hip07 161600802: Erroneous redistributor VLPI base"
>  	default y
> diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
> index 76350b38f0d7a..9220b917ec207 100644
> --- a/arch/arm64/include/asm/cpucaps.h
> +++ b/arch/arm64/include/asm/cpucaps.h
> @@ -66,6 +66,8 @@ cpucap_is_possible(const unsigned int cap)
>  		return IS_ENABLED(CONFIG_ARM64_ERRATUM_3194386);
>  	case ARM64_WORKAROUND_4193714:
>  		return IS_ENABLED(CONFIG_ARM64_ERRATUM_4193714);
> +	case ARM64_WORKAROUND_FUJITSU_030001:
> +		return IS_ENABLED(CONFIG_FUJITSU_ERRATUM_030001);
>  	case ARM64_MPAM:
>  		/*
>  		 * KVM MPAM support doesn't rely on the host kernel supporting MPAM.
> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
> index 14a78ac0f8009..2636c273b8111 100644
> --- a/arch/arm64/include/asm/tlbflush.h
> +++ b/arch/arm64/include/asm/tlbflush.h
> @@ -487,6 +487,39 @@ static __always_inline void __tlbi_range(tlbi_op op, u64 addr,
>  	op(arg);
>  }
>  
> +#ifdef CONFIG_FUJITSU_ERRATUM_030001
> +static __always_inline void fujitsu_erratum_wa(tlbi_op lop, u64 start, u64 end, u16 asid)
> +{
> +	u64 addr;
> +
> +	if (!alternative_has_cap_unlikely(ARM64_WORKAROUND_FUJITSU_030001))
> +		return;
> +
> +	/*
> +	 * The erratum fails to invalidate TLBI entries in the range when
> +	 * addr[34:29] == all 1 && addr[28:0] == all 0 for 512M hugepage.
> +	 * This affects both on S1 and S2 tables and 4k guest may be affected
> +	 * if host uses 64k page size. Therefore it cannot be determined
> +	 * reliably if the target entry is affected or not here. So, always
> +	 * assume hugepage is used.
> +	 * The workaround is to issue extra non-range TLBI ops corresponding
> +	 * to the affected VA or IPA range-based ops in the range.
> +	 */
> +	addr = (start & GENMASK_ULL(63, 35)) | GENMASK_ULL(34, 29);
> +	while (addr < end) {
> +		__tlbi_level_asid(lop, addr, TLBI_TTL_UNKNOWN, asid);
> +		if (addr + BIT_ULL(35) < addr)
> +			/* overflow */
> +			break;
> +		addr += BIT_ULL(35);
> +	}
> +}
> +#else
> +static __always_inline void fujitsu_erratum_wa(tlbi_op lop, u64 start, u64 end, u16 asid)
> +{
> +}
> +#endif /* CONFIG_FUJITSU_ERRATUM_030001 */
> +
>  static __always_inline void __flush_tlb_range_op(tlbi_op lop, tlbi_op rop,
>  						 u64 start, size_t pages,
>  						 u64 stride, u16 asid,
> @@ -518,6 +551,8 @@ static __always_inline void __flush_tlb_range_op(tlbi_op lop, tlbi_op rop,
>  		__tlbi_level_asid(lop, addr, level, asid);
>  		addr += stride;
>  	}
> +
> +	fujitsu_erratum_wa(lop, start, end, asid);
>  }
>  
>  #define __flush_s1_tlb_range_op(op, start, pages, stride, asid, tlb_level) \
> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> index e0c09402540ce..a11135f83e858 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -1039,6 +1039,16 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
>  		.matches = has_impdef_pmuv3,
>  		.cpu_enable = cpu_enable_impdef_pmuv3_traps,
>  	},
> +#ifdef CONFIG_FUJITSU_ERRATUM_030001
> +	{
> +		.desc = "FUJITSU-MONAKA Erratum E#030001",
> +		.capability = ARM64_WORKAROUND_FUJITSU_030001,
> +		ERRATA_MIDR_RANGE_LIST(((const struct midr_range[]) {
> +					MIDR_ALL_VERSIONS(MIDR_FUJITSU_MONAKA),
> +					{}
> +				})),
> +	},
> +#endif
>  	{
>  		.desc = "Known broken GICv3 SEIS implementation",
>  		.capability = ARM64_WORKAROUND_GICv3_BROKEN_SEIS,
> diff --git a/arch/arm64/kvm/hyp/vhe/tlb.c b/arch/arm64/kvm/hyp/vhe/tlb.c
> index c386d9f1c1016..2f1a7fab5eb97 100644
> --- a/arch/arm64/kvm/hyp/vhe/tlb.c
> +++ b/arch/arm64/kvm/hyp/vhe/tlb.c
> @@ -8,6 +8,7 @@
>  
>  #include <asm/kvm_hyp.h>
>  #include <asm/kvm_mmu.h>
> +#include <asm/kvm_nested.h>
>  #include <asm/tlbflush.h>
>  
>  struct tlb_inv_context {
> @@ -218,6 +219,45 @@ void __kvm_flush_vm_context(void)
>  	__tlbi_sync_s1ish_hyp();
>  }
>  
> +#ifdef CONFIG_FUJITSU_ERRATUM_030001
> +static __always_inline void __vae1is(u64 arg)
> +{
> +	__tlbi(vae1is, arg);
> +}
> +static __always_inline void __vale1is(u64 arg)
> +{
> +	__tlbi(vale1is, arg);
> +}
> +static __always_inline void __vaae1is(u64 arg)
> +{
> +	__tlbi(vaae1is, arg);
> +}
> +static __always_inline void __fujitsu_erratum_wa(tlbi_op op, u64 va)
> +{
> +	u64 start, size;
> +	u16 asid;
> +
> +	if (!alternative_has_cap_unlikely(ARM64_WORKAROUND_FUJITSU_030001))
> +		return;
> +
> +	start = decode_range_tlbi(va, &size, &asid);
> +	fujitsu_erratum_wa(op, start, start + size, asid);
> +}
> +#else
> +static __always_inline void __vae1is(u64 arg)
> +{
> +}
> +static __always_inline void __vale1is(u64 arg)
> +{
> +}
> +static __always_inline void __vaae1is(u64 arg)
> +{
> +}
> +static __always_inline void __fujitsu_erratum_wa(tlbi_op op, u64 va)
> +{
> +}
> +#endif
> +
>  /*
>   * TLB invalidation emulation for NV. For any given instruction, we
>   * perform the following transformtions:
> @@ -322,6 +362,7 @@ int __kvm_tlbi_s1e2(struct kvm_s2_mmu *mmu, u64 va, u64 sys_encoding)
>  	case OP_TLBI_RVAE1ISNXS:
>  	case OP_TLBI_RVAE1OSNXS:
>  		__tlbi(rvae1is, va);
> +		__fujitsu_erratum_wa(__vae1is, va);
>  		break;
>  	case OP_TLBI_RVALE2:
>  	case OP_TLBI_RVALE2IS:
> @@ -336,6 +377,7 @@ int __kvm_tlbi_s1e2(struct kvm_s2_mmu *mmu, u64 va, u64 sys_encoding)
>  	case OP_TLBI_RVALE1ISNXS:
>  	case OP_TLBI_RVALE1OSNXS:
>  		__tlbi(rvale1is, va);
> +		__fujitsu_erratum_wa(__vale1is, va);
>  		break;
>  	case OP_TLBI_RVAAE1:
>  	case OP_TLBI_RVAAE1IS:
> @@ -344,6 +386,7 @@ int __kvm_tlbi_s1e2(struct kvm_s2_mmu *mmu, u64 va, u64 sys_encoding)
>  	case OP_TLBI_RVAAE1ISNXS:
>  	case OP_TLBI_RVAAE1OSNXS:
>  		__tlbi(rvaae1is, va);
> +		__fujitsu_erratum_wa(__vaae1is, va);
>  		break;
>  	case OP_TLBI_RVAALE1:
>  	case OP_TLBI_RVAALE1IS:
> @@ -352,6 +395,7 @@ int __kvm_tlbi_s1e2(struct kvm_s2_mmu *mmu, u64 va, u64 sys_encoding)
>  	case OP_TLBI_RVAALE1ISNXS:
>  	case OP_TLBI_RVAALE1OSNXS:
>  		__tlbi(rvaale1is, va);
> +		__fujitsu_erratum_wa(vaale1is, va);
>  		break;
>  	default:
>  		ret = -EINVAL;
> diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
> index 58b6c084f9f25..1e57a0105395b 100644
> --- a/arch/arm64/tools/cpucaps
> +++ b/arch/arm64/tools/cpucaps
> @@ -132,3 +132,4 @@ WORKAROUND_SPECULATIVE_AT
>  WORKAROUND_SPECULATIVE_SSBS
>  WORKAROUND_SPECULATIVE_UNPRIV_LOAD
>  WORKAROUND_BROKEN_AMU_CONSTCNT
> +WORKAROUND_FUJITSU_030001
> 
> -- 
> 2.43.0
> 

Re: [PATCH v2 2/4] arm64: tlb: Add tlbi workaround for FUJITSU-MONAKA Erratum E#030001

[Marc Zyngier]

On Fri, 16 Oct 2026 12:50:17 +0100,
Mark Rutland <mark.rutland@arm.com> wrote:
> 
> On Fri, Oct 16, 2026 at 07:00:46PM +0900, Tomohiro Misono wrote:
> > FUJITSU-MONAKA Erratum E#030001 affects FUJITSU-MONAKA CPU
> > when using TLBI range operations.
> > 
> > On affected FUJITSU-MONAKA CPUs, range-based TLBI operations
> > targeting a VA or IPA may fail to invalidate TLB entries when
> > addr[34:29] == all 1 && addr[28:0] == 0 for 512MB mappings.
> > The affected instructions are:
> >   RVA[L]E{1,2,3}*, RVAA[L]E1*, and RIPAS2[L]E1*.
> > 
> > Work around the erratum by issuing additional non-range
> > TLBI instructions corresponding to the affected VA or IPA
> > range-based TLBI operations.
> > 
> > Signed-off-by: Tomohiro Misono <misono.tomohiro@fujitsu.com>
> 
> As Will and I suggested last time, we'd prefer to disable range
> operations on these parts (and ensure that the relevant ID field is
> hidden from KVM guests).
> 
> Regardless of whether eventually accept the approach you propose here,
> we first need something simple to backport to stable trees (as I assume
> you'll want to run standard Linux distributions on this hardware). The
> TLB invalidation code has changed a lot over time, and I don't think
> it's practical or sensible to backport this patch.
> 
> As a first step, I think we should simply disable the use of range
> operations on these parts, and ensure that KVM hides the relevant ID
> field. After that, we can consider optimizing the workaround, as you
> propose here.
> 
> Marc, does that align with your expectations?

Yes. I'd rather we start with a clean slate so that an unsuspecting
guest cannot get things wrong because it doesn't know about the
erratum. Anything else is icing on the cake that is not desirable at
this stage.

> Is there an existing pattern to follow for hiding the ID field?

Ideally, TLBI_RANGE would be removed from the ID_AA64ISAR0_EL1 copy
that the kernel has, and KVM would simply inherit this. I'm not sure
we have a good way to do that other than doing horrible things with
the override masks.

Otherwise, something as simple as forcing the ID_AA64ISAR0_EL1 reset
value in sys_regs.c would work.

	M.

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

[PATCH v2 3/4] perf: arm_pmu: Add workaround for FUJITSU-MONAKA Erratum E#030002

[Tomohiro Misono]

FUJITSU-MONAKA Erratum E#030002 affects FUJITSU-MONAKA CPU.

On affected FUJITSU-MONAKA CPUs, after a PMU event counter is
stopped at a value just before overflow, an overflow might still
be incorrectly detected, resulting interrupt storm in some case.

For example, if the following conditions are met:
  1) Running perf to count an event in user space only
  2) The event can also occur in kernel space
  3) The counter value is set just before the overflow
     (when using the -F option, initial counter value is -1)

when the kernel is about to return to user space after enabling
the count, an overflow interrupt is incorrectly triggered by an
event that occurred in kernel space. Since the counter value is
not updated (correctly), the interrupt handler does nothing and
returns with the same condition. This leads to another wrong interrupt
and results in an interrupt storm and eventually a softlockup.

Work around the erratum by avoiding programming PMU event counters
with values within five counts of overflow.

Signed-off-by: Tomohiro Misono <misono.tomohiro@fujitsu.com>

---
Changes in v2:
- Add user impact explanation in the commit message
---
---
 Documentation/arch/arm64/silicon-errata.rst |  2 ++
 arch/arm64/Kconfig                          | 17 +++++++++++++++++
 arch/arm64/include/asm/cpucaps.h            |  2 ++
 arch/arm64/kernel/cpu_errata.c              | 10 ++++++++++
 arch/arm64/tools/cpucaps                    |  1 +
 drivers/perf/arm_pmu.c                      | 13 +++++++++++++
 6 files changed, 45 insertions(+)

diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
index 527af20b26468..0efb24ec01b4c 100644
--- a/Documentation/arch/arm64/silicon-errata.rst
+++ b/Documentation/arch/arm64/silicon-errata.rst
@@ -377,6 +377,8 @@ stable kernels.
 +----------------+-----------------+-----------------+-----------------------------+
 | Fujitsu        | MONAKA          | E#030001        | FUJITSU_ERRATUM_030001      |
 +----------------+-----------------+-----------------+-----------------------------+
+| Fujitsu        | MONAKA          | E#030002        | FUJITSU_ERRATUM_030002      |
++----------------+-----------------+-----------------+-----------------------------+
 +----------------+-----------------+-----------------+-----------------------------+
 | ASR            | ASR8601         | #8601001        | N/A                         |
 +----------------+-----------------+-----------------+-----------------------------+
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 5d1a17ab0f593..43fd265156e46 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1361,6 +1361,23 @@ config FUJITSU_ERRATUM_030001
 
 	  If unsure, say Y.
 
+config FUJITSU_ERRATUM_030002
+	bool "FUJITSU-MONAKA erratum E#030002: PMU overflow may be incorrectly detected"
+	depends on ARM_PMUV3
+	default y
+	help
+	  This option adds a workaround for FUJITSU-MONAKA erratum E#030002.
+	  On affected FUJITSU-MONAKA CPUs, after a PMU event counter is
+	  stopped at a value just before overflow, an overflow might still
+	  be incorrectly detected.
+
+	  Work around the erratum by avoiding programming PMU event counters
+	  with values within five counts of overflow.
+
+	  The workaround only affects the FUJITSU-MONAKA.
+
+	  If unsure, say Y.
+
 config HISILICON_ERRATUM_161600802
 	bool "Hip07 161600802: Erroneous redistributor VLPI base"
 	default y
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 9220b917ec207..c0a0452daf949 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -68,6 +68,8 @@ cpucap_is_possible(const unsigned int cap)
 		return IS_ENABLED(CONFIG_ARM64_ERRATUM_4193714);
 	case ARM64_WORKAROUND_FUJITSU_030001:
 		return IS_ENABLED(CONFIG_FUJITSU_ERRATUM_030001);
+	case ARM64_WORKAROUND_FUJITSU_030002:
+		return IS_ENABLED(CONFIG_FUJITSU_ERRATUM_030002);
 	case ARM64_MPAM:
 		/*
 		 * KVM MPAM support doesn't rely on the host kernel supporting MPAM.
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index a11135f83e858..6363b694b4478 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -1048,6 +1048,16 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
 					{}
 				})),
 	},
+#endif
+#ifdef CONFIG_FUJITSU_ERRATUM_030002
+	{
+		.desc = "FUJITSU-MONAKA Erratum E#030002",
+		.capability = ARM64_WORKAROUND_FUJITSU_030002,
+		ERRATA_MIDR_RANGE_LIST(((const struct midr_range[]) {
+					MIDR_ALL_VERSIONS(MIDR_FUJITSU_MONAKA),
+					{}
+				})),
+	},
 #endif
 	{
 		.desc = "Known broken GICv3 SEIS implementation",
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index 1e57a0105395b..ef8ce70ab7121 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -133,3 +133,4 @@ WORKAROUND_SPECULATIVE_SSBS
 WORKAROUND_SPECULATIVE_UNPRIV_LOAD
 WORKAROUND_BROKEN_AMU_CONSTCNT
 WORKAROUND_FUJITSU_030001
+WORKAROUND_FUJITSU_030002
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 1150695653892..c0b8580d80bae 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -234,6 +234,19 @@ int armpmu_event_set_period(struct perf_event *event)
 	if (left > (max_period >> 1))
 		left = (max_period >> 1);
 
+#if IS_ENABLED(CONFIG_ARM64)
+	if (alternative_has_cap_unlikely(ARM64_WORKAROUND_FUJITSU_030002)) {
+		/*
+		 * Due to the errata, overflow might be incorrectly detected in the handler
+		 * when the counter is about to overflow in a single increment, resulting
+		 * interrupt storm in some case. As the counter can increase by up to
+		 * 5 at a time, set 6 here to prevent the condition.
+		 */
+		if (left > 0 && left < 6)
+			left = 6;
+	}
+#endif
+
 	local64_set(&hwc->prev_count, (u64)-left);
 
 	armpmu->write_counter(event, (u64)(-left) & max_period);

-- 
2.43.0

Re: [PATCH v2 3/4] perf: arm_pmu: Add workaround for FUJITSU-MONAKA Erratum E#030002

[sashiko-bot]

> FUJITSU-MONAKA Erratum E#030002 affects FUJITSU-MONAKA CPU.
> 
> On affected FUJITSU-MONAKA CPUs, after a PMU event counter is
> stopped at a value just before overflow, an overflow might still
> be incorrectly detected, resulting interrupt storm in some case.
> 
> For example, if the following conditions are met:
>   1) Running perf to count an event in user space only
>   2) The event can also occur in kernel space
>   3) The counter value is set just before the overflow
>      (when using the -F option, initial counter value is -1)
> 
> when the kernel is about to return to user space after enabling
> the count, an overflow interrupt is incorrectly triggered by an
> event that occurred in kernel space. Since the counter value is
> not updated (correctly), the interrupt handler does nothing and
> returns with the same condition. This leads to another wrong interrupt
> and results in an interrupt storm and eventually a softlockup.
> 
> Work around the erratum by avoiding programming PMU event counters
> with values within five counts of overflow.
> 
> Signed-off-by: Tomohiro Misono <misono.tomohiro@fujitsu.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016-monaka-fix-for-upstream-v2-0-fc7ede7f9f48@fujitsu.com?part=3

Re: [PATCH v2 3/4] perf: arm_pmu: Add workaround for FUJITSU-MONAKA Erratum E#030002

[Mark Rutland]

On Fri, Oct 16, 2026 at 07:00:47PM +0900, Tomohiro Misono wrote:
> FUJITSU-MONAKA Erratum E#030002 affects FUJITSU-MONAKA CPU.
> 
> On affected FUJITSU-MONAKA CPUs, after a PMU event counter is
> stopped at a value just before overflow, an overflow might still
> be incorrectly detected, resulting interrupt storm in some case.
> 
> For example, if the following conditions are met:
>   1) Running perf to count an event in user space only
>   2) The event can also occur in kernel space
>   3) The counter value is set just before the overflow
>      (when using the -F option, initial counter value is -1)
> 
> when the kernel is about to return to user space after enabling
> the count, an overflow interrupt is incorrectly triggered by an
> event that occurred in kernel space. Since the counter value is
> not updated (correctly), the interrupt handler does nothing and
> returns with the same condition. This leads to another wrong interrupt
> and results in an interrupt storm and eventually a softlockup.

I don't fully understand this.

Surely the relevant PMOVS{CLR,SET}[n] bit set as if the counter n
overflowed?

If that bit is set, the handler will certainly do *something*.

If that bit is not set, the interrupt shouldn't be asserted at all. When
does it get de-asserted?

> Work around the erratum by avoiding programming PMU event counters
> with values within five counts of overflow.

Without more detail, I don't think that can be sufficient, because you
can end up in a scenario where:

1. The kernel confugures the counter to -5.

2. The kernel returns to userspace.

3. In userspace, 4 events occur, and are counted, leaving the counter at
   -1.

4. Some unrelated interrupt is taken, entering the kernel.

5. Upon return to userspace, a kernel event occurs, triggering this
   issue.

6. The PMU interupt handler runs, does nothing, leading right back to
   the original issue.

What am I missing?

Mark.

> Signed-off-by: Tomohiro Misono <misono.tomohiro@fujitsu.com>
> 
> ---
> Changes in v2:
> - Add user impact explanation in the commit message
> ---
> ---
>  Documentation/arch/arm64/silicon-errata.rst |  2 ++
>  arch/arm64/Kconfig                          | 17 +++++++++++++++++
>  arch/arm64/include/asm/cpucaps.h            |  2 ++
>  arch/arm64/kernel/cpu_errata.c              | 10 ++++++++++
>  arch/arm64/tools/cpucaps                    |  1 +
>  drivers/perf/arm_pmu.c                      | 13 +++++++++++++
>  6 files changed, 45 insertions(+)
> 
> diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
> index 527af20b26468..0efb24ec01b4c 100644
> --- a/Documentation/arch/arm64/silicon-errata.rst
> +++ b/Documentation/arch/arm64/silicon-errata.rst
> @@ -377,6 +377,8 @@ stable kernels.
>  +----------------+-----------------+-----------------+-----------------------------+
>  | Fujitsu        | MONAKA          | E#030001        | FUJITSU_ERRATUM_030001      |
>  +----------------+-----------------+-----------------+-----------------------------+
> +| Fujitsu        | MONAKA          | E#030002        | FUJITSU_ERRATUM_030002      |
> ++----------------+-----------------+-----------------+-----------------------------+
>  +----------------+-----------------+-----------------+-----------------------------+
>  | ASR            | ASR8601         | #8601001        | N/A                         |
>  +----------------+-----------------+-----------------+-----------------------------+
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 5d1a17ab0f593..43fd265156e46 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1361,6 +1361,23 @@ config FUJITSU_ERRATUM_030001
>  
>  	  If unsure, say Y.
>  
> +config FUJITSU_ERRATUM_030002
> +	bool "FUJITSU-MONAKA erratum E#030002: PMU overflow may be incorrectly detected"
> +	depends on ARM_PMUV3
> +	default y
> +	help
> +	  This option adds a workaround for FUJITSU-MONAKA erratum E#030002.
> +	  On affected FUJITSU-MONAKA CPUs, after a PMU event counter is
> +	  stopped at a value just before overflow, an overflow might still
> +	  be incorrectly detected.
> +
> +	  Work around the erratum by avoiding programming PMU event counters
> +	  with values within five counts of overflow.
> +
> +	  The workaround only affects the FUJITSU-MONAKA.
> +
> +	  If unsure, say Y.
> +
>  config HISILICON_ERRATUM_161600802
>  	bool "Hip07 161600802: Erroneous redistributor VLPI base"
>  	default y
> diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
> index 9220b917ec207..c0a0452daf949 100644
> --- a/arch/arm64/include/asm/cpucaps.h
> +++ b/arch/arm64/include/asm/cpucaps.h
> @@ -68,6 +68,8 @@ cpucap_is_possible(const unsigned int cap)
>  		return IS_ENABLED(CONFIG_ARM64_ERRATUM_4193714);
>  	case ARM64_WORKAROUND_FUJITSU_030001:
>  		return IS_ENABLED(CONFIG_FUJITSU_ERRATUM_030001);
> +	case ARM64_WORKAROUND_FUJITSU_030002:
> +		return IS_ENABLED(CONFIG_FUJITSU_ERRATUM_030002);
>  	case ARM64_MPAM:
>  		/*
>  		 * KVM MPAM support doesn't rely on the host kernel supporting MPAM.
> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> index a11135f83e858..6363b694b4478 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -1048,6 +1048,16 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
>  					{}
>  				})),
>  	},
> +#endif
> +#ifdef CONFIG_FUJITSU_ERRATUM_030002
> +	{
> +		.desc = "FUJITSU-MONAKA Erratum E#030002",
> +		.capability = ARM64_WORKAROUND_FUJITSU_030002,
> +		ERRATA_MIDR_RANGE_LIST(((const struct midr_range[]) {
> +					MIDR_ALL_VERSIONS(MIDR_FUJITSU_MONAKA),
> +					{}
> +				})),
> +	},
>  #endif
>  	{
>  		.desc = "Known broken GICv3 SEIS implementation",
> diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
> index 1e57a0105395b..ef8ce70ab7121 100644
> --- a/arch/arm64/tools/cpucaps
> +++ b/arch/arm64/tools/cpucaps
> @@ -133,3 +133,4 @@ WORKAROUND_SPECULATIVE_SSBS
>  WORKAROUND_SPECULATIVE_UNPRIV_LOAD
>  WORKAROUND_BROKEN_AMU_CONSTCNT
>  WORKAROUND_FUJITSU_030001
> +WORKAROUND_FUJITSU_030002
> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> index 1150695653892..c0b8580d80bae 100644
> --- a/drivers/perf/arm_pmu.c
> +++ b/drivers/perf/arm_pmu.c
> @@ -234,6 +234,19 @@ int armpmu_event_set_period(struct perf_event *event)
>  	if (left > (max_period >> 1))
>  		left = (max_period >> 1);
>  
> +#if IS_ENABLED(CONFIG_ARM64)
> +	if (alternative_has_cap_unlikely(ARM64_WORKAROUND_FUJITSU_030002)) {
> +		/*
> +		 * Due to the errata, overflow might be incorrectly detected in the handler
> +		 * when the counter is about to overflow in a single increment, resulting
> +		 * interrupt storm in some case. As the counter can increase by up to
> +		 * 5 at a time, set 6 here to prevent the condition.
> +		 */
> +		if (left > 0 && left < 6)
> +			left = 6;
> +	}
> +#endif
> +
>  	local64_set(&hwc->prev_count, (u64)-left);
>  
>  	armpmu->write_counter(event, (u64)(-left) & max_period);
> 
> -- 
> 2.43.0
> 

RE: [PATCH v2 3/4] perf: arm_pmu: Add workaround for FUJITSU-MONAKA Erratum E#030002

[Tomohiro Misono (Fujitsu)]

Hi Mark,
Thanks for the reviews.

> Subject: Re: [PATCH v2 3/4] perf: arm_pmu: Add workaround for FUJITSU-MONAKA Erratum E#030002
> 
> On Fri, Oct 16, 2026 at 07:00:47PM +0900, Tomohiro Misono wrote:
> > FUJITSU-MONAKA Erratum E#030002 affects FUJITSU-MONAKA CPU.
> >
> > On affected FUJITSU-MONAKA CPUs, after a PMU event counter is
> > stopped at a value just before overflow, an overflow might still
> > be incorrectly detected, resulting interrupt storm in some case.
> >
> > For example, if the following conditions are met:
> >   1) Running perf to count an event in user space only
> >   2) The event can also occur in kernel space
> >   3) The counter value is set just before the overflow
> >      (when using the -F option, initial counter value is -1)
> >
> > when the kernel is about to return to user space after enabling
> > the count, an overflow interrupt is incorrectly triggered by an
> > event that occurred in kernel space. Since the counter value is
> > not updated (correctly), the interrupt handler does nothing and
> > returns with the same condition. This leads to another wrong interrupt
> > and results in an interrupt storm and eventually a softlockup.
> 
> I don't fully understand this.
> 
> Surely the relevant PMOVS{CLR,SET}[n] bit set as if the counter n
> overflowed?
> 
> If that bit is set, the handler will certainly do *something*.
> 
> If that bit is not set, the interrupt shouldn't be asserted at all. When
> does it get de-asserted?

Sorry, my explanation wasn't clear. The interrupt will be de-asserted as usual.
The problem is that armpmu_event_set_period() will not update the counter
value if, for example, the counter is -1. Therefore, false overflow detection will continue.
With this patch, armpmu_event_set_period() will force the counter to -6 so that
false overflow detection won't occur in the kernel, since the maximum event
count at a time is 5.

> 
> > Work around the erratum by avoiding programming PMU event counters
> > with values within five counts of overflow.
> 
> Without more detail, I don't think that can be sufficient, because you
> can end up in a scenario where:
> 
> 1. The kernel confugures the counter to -5.
> 
> 2. The kernel returns to userspace.
> 
> 3. In userspace, 4 events occur, and are counted, leaving the counter at
>    -1.
> 
> 4. Some unrelated interrupt is taken, entering the kernel.
> 
> 5. Upon return to userspace, a kernel event occurs, triggering this
>    issue.
> 
> 6. The PMU interupt handler runs, does nothing, leading right back to
>    the original issue.
> 
> What am I missing?

When the interrupt is falsely triggered, armpmu_event_set_period() will
force the counter to -6 in this case too. Then, we can return to the user space
without triggering another false overflow.

I hope this answers your questions.
Best Regards,
Tomohiro Misono

> 
> Mark.
> 
> > Signed-off-by: Tomohiro Misono <misono.tomohiro@fujitsu.com>
> >
> > ---
> > Changes in v2:
> > - Add user impact explanation in the commit message
> > ---
> > ---
> >  Documentation/arch/arm64/silicon-errata.rst |  2 ++
> >  arch/arm64/Kconfig                          | 17 +++++++++++++++++
> >  arch/arm64/include/asm/cpucaps.h            |  2 ++
> >  arch/arm64/kernel/cpu_errata.c              | 10 ++++++++++
> >  arch/arm64/tools/cpucaps                    |  1 +
> >  drivers/perf/arm_pmu.c                      | 13 +++++++++++++
> >  6 files changed, 45 insertions(+)
> >
> > diff --git a/Documentation/arch/arm64/silicon-errata.rst
> b/Documentation/arch/arm64/silicon-errata.rst
> > index 527af20b26468..0efb24ec01b4c 100644
> > --- a/Documentation/arch/arm64/silicon-errata.rst
> > +++ b/Documentation/arch/arm64/silicon-errata.rst
> > @@ -377,6 +377,8 @@ stable kernels.
> >  +----------------+-----------------+-----------------+-----------------------------+
> >  | Fujitsu        | MONAKA          | E#030001        | FUJITSU_ERRATUM_030001      |
> >  +----------------+-----------------+-----------------+-----------------------------+
> > +| Fujitsu        | MONAKA          | E#030002        | FUJITSU_ERRATUM_030002      |
> > ++----------------+-----------------+-----------------+-----------------------------+
> >  +----------------+-----------------+-----------------+-----------------------------+
> >  | ASR            | ASR8601         | #8601001        | N/A                         |
> >  +----------------+-----------------+-----------------+-----------------------------+
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 5d1a17ab0f593..43fd265156e46 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -1361,6 +1361,23 @@ config FUJITSU_ERRATUM_030001
> >
> >  	  If unsure, say Y.
> >
> > +config FUJITSU_ERRATUM_030002
> > +	bool "FUJITSU-MONAKA erratum E#030002: PMU overflow may be incorrectly detected"
> > +	depends on ARM_PMUV3
> > +	default y
> > +	help
> > +	  This option adds a workaround for FUJITSU-MONAKA erratum E#030002.
> > +	  On affected FUJITSU-MONAKA CPUs, after a PMU event counter is
> > +	  stopped at a value just before overflow, an overflow might still
> > +	  be incorrectly detected.
> > +
> > +	  Work around the erratum by avoiding programming PMU event counters
> > +	  with values within five counts of overflow.
> > +
> > +	  The workaround only affects the FUJITSU-MONAKA.
> > +
> > +	  If unsure, say Y.
> > +
> >  config HISILICON_ERRATUM_161600802
> >  	bool "Hip07 161600802: Erroneous redistributor VLPI base"
> >  	default y
> > diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
> > index 9220b917ec207..c0a0452daf949 100644
> > --- a/arch/arm64/include/asm/cpucaps.h
> > +++ b/arch/arm64/include/asm/cpucaps.h
> > @@ -68,6 +68,8 @@ cpucap_is_possible(const unsigned int cap)
> >  		return IS_ENABLED(CONFIG_ARM64_ERRATUM_4193714);
> >  	case ARM64_WORKAROUND_FUJITSU_030001:
> >  		return IS_ENABLED(CONFIG_FUJITSU_ERRATUM_030001);
> > +	case ARM64_WORKAROUND_FUJITSU_030002:
> > +		return IS_ENABLED(CONFIG_FUJITSU_ERRATUM_030002);
> >  	case ARM64_MPAM:
> >  		/*
> >  		 * KVM MPAM support doesn't rely on the host kernel supporting MPAM.
> > diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> > index a11135f83e858..6363b694b4478 100644
> > --- a/arch/arm64/kernel/cpu_errata.c
> > +++ b/arch/arm64/kernel/cpu_errata.c
> > @@ -1048,6 +1048,16 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
> >  					{}
> >  				})),
> >  	},
> > +#endif
> > +#ifdef CONFIG_FUJITSU_ERRATUM_030002
> > +	{
> > +		.desc = "FUJITSU-MONAKA Erratum E#030002",
> > +		.capability = ARM64_WORKAROUND_FUJITSU_030002,
> > +		ERRATA_MIDR_RANGE_LIST(((const struct midr_range[]) {
> > +					MIDR_ALL_VERSIONS(MIDR_FUJITSU_MONAKA),
> > +					{}
> > +				})),
> > +	},
> >  #endif
> >  	{
> >  		.desc = "Known broken GICv3 SEIS implementation",
> > diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
> > index 1e57a0105395b..ef8ce70ab7121 100644
> > --- a/arch/arm64/tools/cpucaps
> > +++ b/arch/arm64/tools/cpucaps
> > @@ -133,3 +133,4 @@ WORKAROUND_SPECULATIVE_SSBS
> >  WORKAROUND_SPECULATIVE_UNPRIV_LOAD
> >  WORKAROUND_BROKEN_AMU_CONSTCNT
> >  WORKAROUND_FUJITSU_030001
> > +WORKAROUND_FUJITSU_030002
> > diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> > index 1150695653892..c0b8580d80bae 100644
> > --- a/drivers/perf/arm_pmu.c
> > +++ b/drivers/perf/arm_pmu.c
> > @@ -234,6 +234,19 @@ int armpmu_event_set_period(struct perf_event *event)
> >  	if (left > (max_period >> 1))
> >  		left = (max_period >> 1);
> >
> > +#if IS_ENABLED(CONFIG_ARM64)
> > +	if (alternative_has_cap_unlikely(ARM64_WORKAROUND_FUJITSU_030002)) {
> > +		/*
> > +		 * Due to the errata, overflow might be incorrectly detected in the handler
> > +		 * when the counter is about to overflow in a single increment, resulting
> > +		 * interrupt storm in some case. As the counter can increase by up to
> > +		 * 5 at a time, set 6 here to prevent the condition.
> > +		 */
> > +		if (left > 0 && left < 6)
> > +			left = 6;
> > +	}
> > +#endif
> > +
> >  	local64_set(&hwc->prev_count, (u64)-left);
> >
> >  	armpmu->write_counter(event, (u64)(-left) & max_period);
> >
> > --
> > 2.43.0
> >

Re: [PATCH v2 3/4] perf: arm_pmu: Add workaround for FUJITSU-MONAKA Erratum E#030002

[Mark Rutland]

On Fri, Oct 16, 2026 at 01:00:13PM +0000, Tomohiro Misono (Fujitsu) wrote:
> > Subject: Re: [PATCH v2 3/4] perf: arm_pmu: Add workaround for FUJITSU-MONAKA Erratum E#030002
> > 
> > On Fri, Oct 16, 2026 at 07:00:47PM +0900, Tomohiro Misono wrote:
> > > FUJITSU-MONAKA Erratum E#030002 affects FUJITSU-MONAKA CPU.
> > >
> > > On affected FUJITSU-MONAKA CPUs, after a PMU event counter is
> > > stopped at a value just before overflow, an overflow might still
> > > be incorrectly detected, resulting interrupt storm in some case.
> > >
> > > For example, if the following conditions are met:
> > >   1) Running perf to count an event in user space only
> > >   2) The event can also occur in kernel space
> > >   3) The counter value is set just before the overflow
> > >      (when using the -F option, initial counter value is -1)
> > >
> > > when the kernel is about to return to user space after enabling
> > > the count, an overflow interrupt is incorrectly triggered by an
> > > event that occurred in kernel space. Since the counter value is
> > > not updated (correctly), the interrupt handler does nothing and
> > > returns with the same condition. This leads to another wrong interrupt
> > > and results in an interrupt storm and eventually a softlockup.
> > 
> > I don't fully understand this.
> > 
> > Surely the relevant PMOVS{CLR,SET}[n] bit set as if the counter n
> > overflowed?
> > 
> > If that bit is set, the handler will certainly do *something*.
> > 
> > If that bit is not set, the interrupt shouldn't be asserted at all. When
> > does it get de-asserted?
> 
> Sorry, my explanation wasn't clear. The interrupt will be de-asserted
> as usual.

I'm trying to work out which of the following happens due to the
erratum:

(a) When the erratum occurs, the HW sets a bit in PMOVS*. An overflow
    interrupt is asserted because PMOVS* is non-zero. The overflow
    handler will see that bit was set in PMOVS*. Clearing PMOVS*
    de-asserts the interrupt as usual.

(b) When the erratum occurs, the HW does not set a bit in PMOVS*, and
    asserts an overflow interrupt even if PMOVS* is clear.  The overflow
    handler might not see a bit set in PMOVS*.

(c) Something else.

Can you pleaes confirm what HW does with PMOVS* when the erratum occurs?
I assume (a), but you haven't explicitly stated that so far.

> The problem is that armpmu_event_set_period() will not update the counter
> value if, for example, the counter is -1. Therefore, false overflow detection will continue.
> With this patch, armpmu_event_set_period() will force the counter to -6 so that
> false overflow detection won't occur in the kernel, since the maximum event
> count at a time is 5.

I expected that were this to occur a number of times in quick
succession, the core perf code would throttle the event, and adjust the
period.

I am presumably missing some detail that prevents that.

I assume you've seen the issue in practice? i.e. you've actucally
triggered this with the perf tool on real hardware?

Mark.

[PATCH v2 4/4] irqchip/gicv3: Add workaround for FUJITSU-MONAKA erratum E#030003

[Tomohiro Misono]

From: Kohei Enju <enju.kohei@fujitsu.com>

On affected FUJITSU-MONAKA CPUs, the erratum may occur when an SGI is
generated by writing to ICC_SGI0R_EL1, ICC_SGI1R_EL1, or ICC_ASGI1R_EL1,
if the operation races with CPU interface processing triggered by the
arrival of a higher-priority interrupt, an update to a pending
interrupt, or a transition of the PE to the Sleep state. When the
erratum occurs, the SGI is lost and the system register write does not
complete, causing the issuing core to hang.

Guest accesses to these registers are not affected by this erratum, as
they are trapped to EL2 and handled without issuing the affected system
register write.

Work around the erratum by writing 1 to the bit corresponding to the
target SGI INTID in GICR_ISPENDR0 of each target PE's GIC Redistributor,
instead of writing to the affected system registers.

Accessing a target PE's GICR_ISPENDR0 requires its Redistributor base to
have been discovered. Affected platforms conform to SBBR, which requires
PSCI for secondary CPU boot. They therefore do not use the ACPI Parking
protocol, which sends an IPI before the secondary CPU has initialized
its Redistributor. With PSCI, a secondary CPU discovers its
Redistributor before becoming an IPI target.

Signed-off-by: Kohei Enju <enju.kohei@fujitsu.com>
---
Changes in v2:
- Clarify the erratum description and document that virtual accesses are
  unaffected.
- Remove the gic_send_sgi_via_rdist() helper.
- Remove the write-count rationale.
- Use the CPU MIDR instead of the SoC ID for filtering.

Note that I have left the dsb(st) after the GICR_ISPENDR0 writes
unchanged, pending clarification of the required completion point. If
the writes must be observed by a specific component before
gic_ipi_send_mask() returns, I will use the appropriate mechanism to
provide that guarantee.
---
---
 Documentation/arch/arm64/silicon-errata.rst |  2 ++
 drivers/irqchip/irq-gic-v3.c                | 32 +++++++++++++++++++++++++++++
 2 files changed, 34 insertions(+)

diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
index 0efb24ec01b4c..ee957494a5513 100644
--- a/Documentation/arch/arm64/silicon-errata.rst
+++ b/Documentation/arch/arm64/silicon-errata.rst
@@ -379,6 +379,8 @@ stable kernels.
 +----------------+-----------------+-----------------+-----------------------------+
 | Fujitsu        | MONAKA          | E#030002        | FUJITSU_ERRATUM_030002      |
 +----------------+-----------------+-----------------+-----------------------------+
+| Fujitsu        | MONAKA GICv3/v4 | E#030003        | N/A                         |
++----------------+-----------------+-----------------+-----------------------------+
 +----------------+-----------------+-----------------+-----------------------------+
 | ASR            | ASR8601         | #8601001        | N/A                         |
 +----------------+-----------------+-----------------+-----------------------------+
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 6e1fa5b247fc4..125940442d77a 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -80,6 +80,8 @@ static DEFINE_STATIC_KEY_FALSE(gic_nvidia_t241_erratum);
 
 static DEFINE_STATIC_KEY_FALSE(gic_arm64_2941627_erratum);
 
+static DEFINE_STATIC_KEY_FALSE(gic_fujitsu_030003_erratum);
+
 static struct gic_chip_data gic_data __read_mostly;
 static DEFINE_STATIC_KEY_TRUE(supports_deactivate_key);
 
@@ -238,6 +240,9 @@ static DEFINE_PER_CPU(bool, has_rss);
 #define gic_data_rdist()		(this_cpu_ptr(gic_data.rdists.rdist))
 #define gic_data_rdist_rd_base()	(gic_data_rdist()->rd_base)
 #define gic_data_rdist_sgi_base()	(gic_data_rdist_rd_base() + SZ_64K)
+#define gic_data_rdist_cpu(cpu)		(per_cpu_ptr(gic_data.rdists.rdist, cpu))
+#define gic_data_rdist_rd_base_cpu(cpu)	(gic_data_rdist_cpu(cpu)->rd_base)
+#define gic_data_rdist_sgi_base_cpu(cpu)	(gic_data_rdist_rd_base_cpu(cpu) + SZ_64K)
 
 /* Our default, arbitrary priority value. Linux only uses one anyway. */
 #define DEFAULT_PMR_VALUE	0xf0
@@ -1386,6 +1391,17 @@ static void gic_ipi_send_mask(struct irq_data *d, const struct cpumask *mask)
 	 */
 	dsb(ishst);
 
+	if (static_branch_unlikely(&gic_fujitsu_030003_erratum)) {
+		for_each_cpu(cpu, mask) {
+			void __iomem *base = gic_data_rdist_sgi_base_cpu(cpu);
+
+			writel_relaxed(BIT(d->hwirq), base + GICR_ISPENDR0);
+		}
+
+		dsb(st);
+		return;
+	}
+
 	for_each_cpu(cpu, mask) {
 		u64 cluster_id = MPIDR_TO_SGI_CLUSTER_ID(gic_cpu_to_affinity(cpu));
 		u16 tlist;
@@ -1871,6 +1887,16 @@ static bool gic_enable_quirk_rk3399(void *data)
 	return false;
 }
 
+static bool gic_enable_quirk_fujitsu_030003(void *data)
+{
+	if (read_cpuid_implementor() != ARM_CPU_IMP_FUJITSU ||
+	    read_cpuid_part_number() != FUJITSU_CPU_PART_MONAKA)
+		return false;
+
+	static_branch_enable(&gic_fujitsu_030003_erratum);
+	return true;
+}
+
 static bool rd_set_non_coherent(void *data)
 {
 	struct gic_chip_data *d = data;
@@ -1951,6 +1977,12 @@ static const struct gic_quirk gic_quirks[] = {
 		.mask	= 0xff000fff,
 		.init	= gic_enable_quirk_rk3399,
 	},
+	{
+		.desc	= "GICv3: Fujitsu erratum 030003",
+		.iidr	= 0x0403043b,
+		.mask	= 0xffffffff,
+		.init	= gic_enable_quirk_fujitsu_030003,
+	},
 	{
 	}
 };

-- 
2.43.0

Re: [PATCH v2 4/4] irqchip/gicv3: Add workaround for FUJITSU-MONAKA erratum E#030003

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] irqchip/gic-v3: IPI via GICR_ISPENDR0 targets sleeping redistributor
- [High] irqchip/gicv3: missing NULL check on rd_base causes IPI sender crash
--

commit 98989a1fb6fe6471377f9b9c4a24e0097c1639a3
Author: Kohei Enju <enju.kohei@fujitsu.com>

irqchip/gicv3: Add workaround for FUJITSU-MONAKA erratum E#030003

This patch works around a FUJITSU-MONAKA erratum where SGIs are lost if an
SGI generation races with CPU interface processing. It addresses the issue
by bypassing the affected system registers and directly writing to the target
CPU's GICR_ISPENDR0 over MMIO.

> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
[ ... ]
> @@ -1386,6 +1391,17 @@ static void gic_ipi_send_mask(struct irq_data *d, const struct cpumask *mask)
>  	 */
>  	dsb(ishst);
>  
> +	if (static_branch_unlikely(&gic_fujitsu_030003_erratum)) {
> +		for_each_cpu(cpu, mask) {
> +			void __iomem *base = gic_data_rdist_sgi_base_cpu(cpu);

[Severity: High]
Could this cause a fatal page fault on the CPU sending the IPI if the target
CPU failed to initialize its redistributor?

If a secondary CPU fails to initialize its GIC redistributor due to a buggy
ACPI MADT or missing DT entry, rd_base remains NULL. However, the CPU can
still come online because gic_starting_cpu() returns 0 on failure.

When another CPU later broadcasts an IPI, this workaround will derive base
from a NULL rd_base, resulting in an unmapped address (0x10000). The sender
CPU will then crash when attempting the writel_relaxed().

Should we validate that the target CPU actually has an initialized
redistributor base before bypassing the architected SGI system registers?

> +
> +			writel_relaxed(BIT(d->hwirq), base + GICR_ISPENDR0);

[Severity: High]
Is it safe to write to a target CPU's GICR_ISPENDR0 directly over MMIO when
that CPU might be in deep idle?

During deep idle, such as via PSCI, the target CPU's redistributor is put
to sleep (ProcessorSleep=1 either via gic_cpu_pm_notifier or firmware).
According to the GICv3 architecture, writing to a redistributor register
(other than GICR_WAKER or GICR_TYPER) when ProcessorSleep=1 is constrained
unpredictable.

Normal kernel operations, like the scheduler sending smp_send_reschedule()
to an idle CPU, will hit this path. If the hardware ignores the write, the
IPI is dropped, which can lead to deadlocks in smp_call_function() or lost
wakeups.

> +		}
> +
> +		dsb(st);
> +		return;
> +	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016-monaka-fix-for-upstream-v2-0-fc7ede7f9f48@fujitsu.com?part=4

Re: [PATCH v2 4/4] irqchip/gicv3: Add workaround for FUJITSU-MONAKA erratum E#030003

[kernel test robot]

Hi Tomohiro,

kernel test robot noticed the following build errors:

[auto build test ERROR on 24a19b953e2a3d0ea5a8c4951a0ab8f32720c907]

url:    https://github.com/intel-lab-lkp/linux/commits/Tomohiro-Misono/arm64-cputype-Add-FUJITSU-MONAKA-definition/20261016-190045
base:   24a19b953e2a3d0ea5a8c4951a0ab8f32720c907
patch link:    https://lore.kernel.org/r/20261016-monaka-fix-for-upstream-v2-4-fc7ede7f9f48%40fujitsu.com
patch subject: [PATCH v2 4/4] irqchip/gicv3: Add workaround for FUJITSU-MONAKA erratum E#030003
config: arm-defconfig (https://download.01.org/0day-ci/archive/20261017/202610171939.VWCcPPra-lkp@intel.com/config)
compiler: clang version 24.0.0git (https://github.com/llvm/llvm-project 6719b9e31d6a93099612c474eec76d9f41d0275a)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20261017/202610171939.VWCcPPra-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202610171939.VWCcPPra-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/irqchip/irq-gic-v3.c:1892:34: error: use of undeclared identifier 'ARM_CPU_IMP_FUJITSU'
    1892 |         if (read_cpuid_implementor() != ARM_CPU_IMP_FUJITSU ||
         |                                         ^~~~~~~~~~~~~~~~~~~
>> drivers/irqchip/irq-gic-v3.c:1893:34: error: use of undeclared identifier 'FUJITSU_CPU_PART_MONAKA'
    1893 |             read_cpuid_part_number() != FUJITSU_CPU_PART_MONAKA)
         |                                         ^~~~~~~~~~~~~~~~~~~~~~~
   2 errors generated.


vim +/ARM_CPU_IMP_FUJITSU +1892 drivers/irqchip/irq-gic-v3.c

  1889	
  1890	static bool gic_enable_quirk_fujitsu_030003(void *data)
  1891	{
> 1892		if (read_cpuid_implementor() != ARM_CPU_IMP_FUJITSU ||
> 1893		    read_cpuid_part_number() != FUJITSU_CPU_PART_MONAKA)
  1894			return false;
  1895	
  1896		static_branch_enable(&gic_fujitsu_030003_erratum);
  1897		return true;
  1898	}
  1899	

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v2 4/4] irqchip/gicv3: Add workaround for FUJITSU-MONAKA erratum E#030003

[Marc Zyngier]

On Fri, 16 Oct 2026 11:00:48 +0100,
Tomohiro Misono <misono.tomohiro@fujitsu.com> wrote:
> 
> From: Kohei Enju <enju.kohei@fujitsu.com>
> 
> On affected FUJITSU-MONAKA CPUs, the erratum may occur when an SGI is
> generated by writing to ICC_SGI0R_EL1, ICC_SGI1R_EL1, or ICC_ASGI1R_EL1,
> if the operation races with CPU interface processing triggered by the
> arrival of a higher-priority interrupt, an update to a pending
> interrupt, or a transition of the PE to the Sleep state. When the
> erratum occurs, the SGI is lost and the system register write does not
> complete, causing the issuing core to hang.
> 
> Guest accesses to these registers are not affected by this erratum, as
> they are trapped to EL2 and handled without issuing the affected system
> register write.
> 
> Work around the erratum by writing 1 to the bit corresponding to the
> target SGI INTID in GICR_ISPENDR0 of each target PE's GIC Redistributor,
> instead of writing to the affected system registers.
> 
> Accessing a target PE's GICR_ISPENDR0 requires its Redistributor base to
> have been discovered. Affected platforms conform to SBBR, which requires
> PSCI for secondary CPU boot. They therefore do not use the ACPI Parking
> protocol, which sends an IPI before the secondary CPU has initialized
> its Redistributor. With PSCI, a secondary CPU discovers its
> Redistributor before becoming an IPI target.
> 
> Signed-off-by: Kohei Enju <enju.kohei@fujitsu.com>

You are posting a patch on behalf of someone else, you need to add
your own SoB:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v7.3-rc7#n448

> ---
> Changes in v2:
> - Clarify the erratum description and document that virtual accesses are
>   unaffected.
> - Remove the gic_send_sgi_via_rdist() helper.
> - Remove the write-count rationale.
> - Use the CPU MIDR instead of the SoC ID for filtering.
> 
> Note that I have left the dsb(st) after the GICR_ISPENDR0 writes
> unchanged, pending clarification of the required completion point. If
> the writes must be observed by a specific component before
> gic_ipi_send_mask() returns, I will use the appropriate mechanism to
> provide that guarantee.

See below.

[...]

> @@ -1386,6 +1391,17 @@ static void gic_ipi_send_mask(struct irq_data *d, const struct cpumask *mask)
>  	 */
>  	dsb(ishst);
>  
> +	if (static_branch_unlikely(&gic_fujitsu_030003_erratum)) {
> +		for_each_cpu(cpu, mask) {
> +			void __iomem *base = gic_data_rdist_sgi_base_cpu(cpu);
> +
> +			writel_relaxed(BIT(d->hwirq), base + GICR_ISPENDR0);
> +		}
> +
> +		dsb(st);

What is this DSB achieving? As far as I can tell, not much. The memory
type is nGnRE, so DSB doesn't force writes to reach the end-point, and
only guarantee ordering that system register SGI generation doesn't
provide.

So either

(a) there is a functional requirement on this HW to have a DSB, and
    needs to be documented,

(b) or there is a need for end-point synchronisation, which needs to
    be enforced by a read back (knowing that the sysreg doesn't
    provide this guarantee), and this needs to be documented,

(c) or this is completely superfluous and can be dropped

Which case are we in?

Thanks,

	M.

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