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

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

[Tomohiro Misono]

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 and 3
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-rc5.

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           | 33 ++++++++++++++++++++
 arch/arm64/kernel/cpu_errata.c              | 20 ++++++++++++
 arch/arm64/tools/cpucaps                    |  2 ++
 drivers/irqchip/irq-gic-v3.c                | 48 +++++++++++++++++++++++++++++
 drivers/perf/arm_pmu.c                      | 13 ++++++++
 9 files changed, 164 insertions(+)
---
base-commit: 72d3fcf802c45d00b300f25b848a93c3a2bd7c7e
change-id: 20261002-monaka-fix-for-upstream-680801dea92f

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

[PATCH 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 1fa29616e586..3f648cb10e61 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 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 64k page size.

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>
---
 Documentation/arch/arm64/silicon-errata.rst |  2 ++
 arch/arm64/Kconfig                          | 19 +++++++++++++++++
 arch/arm64/include/asm/cpucaps.h            |  2 ++
 arch/arm64/include/asm/tlbflush.h           | 33 +++++++++++++++++++++++++++++
 arch/arm64/kernel/cpu_errata.c              | 10 +++++++++
 arch/arm64/tools/cpucaps                    |  1 +
 6 files changed, 67 insertions(+)

diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
index ac3248b9f2f3..8ab6284e3d10 100644
--- a/Documentation/arch/arm64/silicon-errata.rst
+++ b/Documentation/arch/arm64/silicon-errata.rst
@@ -373,6 +373,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 b5a51b0ef944..38248a31d5f1 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1312,6 +1312,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"
+	depends on PAGE_SIZE_64KB
+	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
+	  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.
+
+	  The erratum only affects the FUJITSU-MONAKA on 64k pagesize.
+
+	  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 76350b38f0d7..9220b917ec20 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 14a78ac0f800..0487daec1652 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -487,6 +487,37 @@ static __always_inline void __tlbi_range(tlbi_op op, u64 addr,
 	op(arg);
 }
 
+#ifdef CONFIG_FUJITSU_ERRATUM_030001
+static 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.
+	 * However, since it cannot be determined reliably if the target
+	 * entry is hugepage or not here, 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 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 +549,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 8ec47d89b45b..5b9dea3c761d 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -1027,6 +1027,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/tools/cpucaps b/arch/arm64/tools/cpucaps
index 2775ba3359cf..50a9aa0e2bf0 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -132,3 +132,4 @@ WORKAROUND_REPEAT_TLBI_SYNC
 WORKAROUND_SPECULATIVE_AT
 WORKAROUND_SPECULATIVE_SSBS
 WORKAROUND_SPECULATIVE_UNPRIV_LOAD
+WORKAROUND_FUJITSU_030001

-- 
2.43.0

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

[Will Deacon]

On Fri, Oct 02, 2026 at 07:26:50PM +0900, Tomohiro Misono wrote:
> FUJITSU-MONAKA Erratum E#030001 affects FUJITSU-MONAKA CPU
> when using 64k page size.
> 
> 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.

Why don't we just avoid using range invalidation on these parts instead?

Will

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

[Mark Rutland]

On Fri, Oct 02, 2026 at 07:26:50PM +0900, Tomohiro Misono wrote:
> FUJITSU-MONAKA Erratum E#030001 affects FUJITSU-MONAKA CPU
> when using 64k page size.
> 
> 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*.

How does this work when all of the following are true:

* The S1 translation granule is 4K.
* The S2 translation granule is 64K.
* S1 has a 1G block translating VA x to IPA y.
* S2 has a 512M block translating IPA y to PA z.

In that case, can a "512MB mapping" exist for VA x? I would expect so.

Assuming that is the case, the S1 translation granule doesn't matter,
and the S1 workaround cannot depend on PAGE_SIZE_64KB.

> 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>
> ---
>  Documentation/arch/arm64/silicon-errata.rst |  2 ++
>  arch/arm64/Kconfig                          | 19 +++++++++++++++++
>  arch/arm64/include/asm/cpucaps.h            |  2 ++
>  arch/arm64/include/asm/tlbflush.h           | 33 +++++++++++++++++++++++++++++
>  arch/arm64/kernel/cpu_errata.c              | 10 +++++++++
>  arch/arm64/tools/cpucaps                    |  1 +
>  6 files changed, 67 insertions(+)
> 
> diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
> index ac3248b9f2f3..8ab6284e3d10 100644
> --- a/Documentation/arch/arm64/silicon-errata.rst
> +++ b/Documentation/arch/arm64/silicon-errata.rst
> @@ -373,6 +373,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 b5a51b0ef944..38248a31d5f1 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1312,6 +1312,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"
> +	depends on PAGE_SIZE_64KB

As above, I strongly suspect this depends on the conbiation of S1 and S2
sizes, and could happen regardless of whether S1 uses 64K.

> +	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
> +	  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.
> +
> +	  The erratum only affects the FUJITSU-MONAKA on 64k pagesize.
> +
> +	  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 76350b38f0d7..9220b917ec20 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 14a78ac0f800..0487daec1652 100644
> --- a/arch/arm64/include/asm/tlbflush.h
> +++ b/arch/arm64/include/asm/tlbflush.h
> @@ -487,6 +487,37 @@ static __always_inline void __tlbi_range(tlbi_op op, u64 addr,
>  	op(arg);
>  }
>  
> +#ifdef CONFIG_FUJITSU_ERRATUM_030001
> +static 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.
> +	 * However, since it cannot be determined reliably if the target
> +	 * entry is hugepage or not here, 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 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 +549,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);
>  }

It would be much simpler to say range invalidation doesn't work on this
part.

>  
>  #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 8ec47d89b45b..5b9dea3c761d 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -1027,6 +1027,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),
> +					{}
> +				})),
> +	},

Are you expecting to add other parts here?

Is there a (future?) revision of MONAKA with this fixed?

Mark.

> +#endif
>  	{
>  		.desc = "Known broken GICv3 SEIS implementation",
>  		.capability = ARM64_WORKAROUND_GICv3_BROKEN_SEIS,
> diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
> index 2775ba3359cf..50a9aa0e2bf0 100644
> --- a/arch/arm64/tools/cpucaps
> +++ b/arch/arm64/tools/cpucaps
> @@ -132,3 +132,4 @@ WORKAROUND_REPEAT_TLBI_SYNC
>  WORKAROUND_SPECULATIVE_AT
>  WORKAROUND_SPECULATIVE_SSBS
>  WORKAROUND_SPECULATIVE_UNPRIV_LOAD
> +WORKAROUND_FUJITSU_030001
> 
> -- 
> 2.43.0
> 

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

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>
---
 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 8ab6284e3d10..429bdf9a3d9d 100644
--- a/Documentation/arch/arm64/silicon-errata.rst
+++ b/Documentation/arch/arm64/silicon-errata.rst
@@ -375,6 +375,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 38248a31d5f1..348d9836d2c2 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1331,6 +1331,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 9220b917ec20..c0a0452daf94 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 5b9dea3c761d..aa1dd1ae0f92 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -1036,6 +1036,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 50a9aa0e2bf0..6bf19fc68def 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -133,3 +133,4 @@ WORKAROUND_SPECULATIVE_AT
 WORKAROUND_SPECULATIVE_SSBS
 WORKAROUND_SPECULATIVE_UNPRIV_LOAD
 WORKAROUND_FUJITSU_030001
+WORKAROUND_FUJITSU_030002
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 115069565389..c0b8580d80ba 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 3/4] perf: arm_pmu: Add workaround for FUJITSU-MONAKA Erratum E#030002

[Will Deacon]

On Fri, Oct 02, 2026 at 07:26:51PM +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.
> 
> Work around the erratum by avoiding programming PMU event counters
> with values within five counts of overflow.

What's the user-visible behaviour of this erratum? It's not entirely clear
to me why we need to do anything at all.

Will

[PATCH 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, an SGI generated by writing to
ICC_SGI0R_EL1, ICC_SGI1R_EL1, or ICC_ASGI1R_EL1 may be lost 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 this occurs, the system
register write does not complete, causing the issuing core to hang.

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.

The affinity topology of affected systems has Aff0 == 0 for every PE,
with PEs distinguished by higher affinity levels. Consequently, an
ICC_SGI1R_EL1 write can target only one PE, so the workaround does not
increase the number of writes required to send an SGI to multiple PEs.

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>
---
 Documentation/arch/arm64/silicon-errata.rst |  2 ++
 drivers/irqchip/irq-gic-v3.c                | 48 +++++++++++++++++++++++++++++
 2 files changed, 50 insertions(+)

diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
index 429bdf9a3d9d..13328a30df59 100644
--- a/Documentation/arch/arm64/silicon-errata.rst
+++ b/Documentation/arch/arm64/silicon-errata.rst
@@ -377,6 +377,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 6e1fa5b247fc..e73fea8a0e27 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
@@ -1373,6 +1378,13 @@ static void gic_send_sgi(u64 cluster_id, u16 tlist, unsigned int irq)
 	gic_write_sgi1r(val);
 }
 
+static void gic_send_sgi_via_rdist(int cpu, unsigned int irq)
+{
+	void __iomem *base = gic_data_rdist_sgi_base_cpu(cpu);
+
+	writel_relaxed(BIT(irq), base + GICR_ISPENDR0);
+}
+
 static void gic_ipi_send_mask(struct irq_data *d, const struct cpumask *mask)
 {
 	int cpu;
@@ -1386,6 +1398,22 @@ static void gic_ipi_send_mask(struct irq_data *d, const struct cpumask *mask)
 	 */
 	dsb(ishst);
 
+	if (static_branch_unlikely(&gic_fujitsu_030003_erratum)) {
+		/*
+		 * The affinity topology of affected systems has Aff0 == 0 for
+		 * every PE; PEs are distinguished by higher affinity levels.
+		 * ICC_SGI1R_EL1 therefore targets only one PE per write, so
+		 * using GICR_ISPENDR0 does not increase the number of writes
+		 * required to send an SGI to multiple PEs.
+		 */
+		for_each_cpu(cpu, mask)
+			gic_send_sgi_via_rdist(cpu, d->hwirq);
+
+		/* Force the above writes to GICR_ISPENDR0 to be executed */
+		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 +1899,20 @@ static bool gic_enable_quirk_rk3399(void *data)
 	return false;
 }
 
+#define SMCCC_SOC_ID_FUJITSU_MONAKA	0x00040003
+
+static bool gic_enable_quirk_fujitsu_030003(void *data)
+{
+	s32 soc_id = arm_smccc_get_soc_id_version();
+
+	/* Check JEP106 code for FUJITSU-MONAKA chip (0004:0003) */
+	if (soc_id != SMCCC_SOC_ID_FUJITSU_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 +1993,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 4/4] irqchip/gicv3: Add workaround for FUJITSU-MONAKA erratum E#030003

[Marc Zyngier]

On Fri, 02 Oct 2026 11:26:52 +0100,
Tomohiro Misono <misono.tomohiro@fujitsu.com> wrote:
> 
> From: Kohei Enju <enju.kohei@fujitsu.com>
> 
> On affected FUJITSU-MONAKA CPUs, an SGI generated by writing to
> ICC_SGI0R_EL1, ICC_SGI1R_EL1, or ICC_ASGI1R_EL1 may be lost 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 this occurs, the system
> register write does not complete, causing the issuing core to hang.
>

Is the SGI lost? Or is the sender core hanging?

I expect that virtualised accesses to these registers are not
affected, since they trap, but it'd be good to document this.

> 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.
> 
> The affinity topology of affected systems has Aff0 == 0 for every PE,
> with PEs distinguished by higher affinity levels. Consequently, an
> ICC_SGI1R_EL1 write can target only one PE, so the workaround does not
> increase the number of writes required to send an SGI to multiple PEs.
>
> 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>
> ---
>  Documentation/arch/arm64/silicon-errata.rst |  2 ++
>  drivers/irqchip/irq-gic-v3.c                | 48 +++++++++++++++++++++++++++++
>  2 files changed, 50 insertions(+)
> 
> diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
> index 429bdf9a3d9d..13328a30df59 100644
> --- a/Documentation/arch/arm64/silicon-errata.rst
> +++ b/Documentation/arch/arm64/silicon-errata.rst
> @@ -377,6 +377,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 6e1fa5b247fc..e73fea8a0e27 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
> @@ -1373,6 +1378,13 @@ static void gic_send_sgi(u64 cluster_id, u16 tlist, unsigned int irq)
>  	gic_write_sgi1r(val);
>  }
>  
> +static void gic_send_sgi_via_rdist(int cpu, unsigned int irq)
> +{
> +	void __iomem *base = gic_data_rdist_sgi_base_cpu(cpu);
> +
> +	writel_relaxed(BIT(irq), base + GICR_ISPENDR0);
> +}
> +

I don't think there is any need for a helper, given that there is a
single caller.

>  static void gic_ipi_send_mask(struct irq_data *d, const struct cpumask *mask)
>  {
>  	int cpu;
> @@ -1386,6 +1398,22 @@ static void gic_ipi_send_mask(struct irq_data *d, const struct cpumask *mask)
>  	 */
>  	dsb(ishst);
>  
> +	if (static_branch_unlikely(&gic_fujitsu_030003_erratum)) {
> +		/*
> +		 * The affinity topology of affected systems has Aff0 == 0 for
> +		 * every PE; PEs are distinguished by higher affinity levels.
> +		 * ICC_SGI1R_EL1 therefore targets only one PE per write, so
> +		 * using GICR_ISPENDR0 does not increase the number of writes
> +		 * required to send an SGI to multiple PEs.

This is not about the number of writes, but the cost of individual
writes. A sysreg access is almost free (at least it is on decent
implementations), while an MMIO access is probably one of the worst
offenders. Therefore implying that there is no extra overhead is
likely to be misleading. The commit message has the same problem.

In any case, I don't think you need to justify anything here, as the
choice between costly SGIs and a dead CPU is pretty moot.

> +		 */
> +		for_each_cpu(cpu, mask)
> +			gic_send_sgi_via_rdist(cpu, d->hwirq);
> +
> +		/* Force the above writes to GICR_ISPENDR0 to be executed */
> +		dsb(st);

This doesn't force things to be executed. This is about completion of
the access, and with an nGnRE mapping, it doesn't enforce that the
stores actually reach the RDs, only an arbitrary point in the memory
subsystem.  The only way to guarantee this is to perform a read-back.

If this is relying on some additional properties that are
implementation specific, then this requires to be documented (for
example, if the implementation treats nGnRE as nGnRnE).

> +		return;
> +	}
> +
>  	for_each_cpu(cpu, mask) {
>  		u64 cluster_id = MPIDR_TO_SGI_CLUSTER_ID(gic_cpu_to_affinity(cpu));
>  		u16 tlist;
> @@ -1871,6 +1899,20 @@ static bool gic_enable_quirk_rk3399(void *data)
>  	return false;
>  }
>  
> +#define SMCCC_SOC_ID_FUJITSU_MONAKA	0x00040003
> +
> +static bool gic_enable_quirk_fujitsu_030003(void *data)
> +{
> +	s32 soc_id = arm_smccc_get_soc_id_version();
> +
> +	/* Check JEP106 code for FUJITSU-MONAKA chip (0004:0003) */
> +	if (soc_id != SMCCC_SOC_ID_FUJITSU_MONAKA)
> +		return false;

Why is this keyed on some firmware interface, while it is the CPU
interface that is at fault? I'd expect that looking at the MIDR would
be more reliable.

> +
> +	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 +1993,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,

Same problem. This is looking that the distributor instead of the CPU.
It's OK to use it as a proxy for further filtering, but the final
decision should probably rest on the MIDR.

Thanks,

	M.

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