kernel/linux.git/Documentation/arch, branch v6.12.94

arm64: errata: Mitigate TLBI errata on Microsoft Azure Cobalt 100 CPU

2026-06-19T11:42:39+00:00

commit 1940e70a8144bf75e6df26bf6f600862ea7f7ea1 upstream. Commit fb091ff39479 ("arm64: Subscribe Microsoft Azure Cobalt 100 to ARM Neoverse N2 errata") states that Microsoft Azure Cobalt 100 CPU "is a Microsoft implemented CPU based on r0p0 of the ARM Neoverse N2 CPU, and therefore suffers from all the same errata.". So enable the workaround for the latest broadcast TLB invalidation bug on these parts. Signed-off-by: Will Deacon [Mark: backport to v6.12.y] Signed-off-by: Mark Rutland Signed-off-by: Greg Kroah-Hartman

arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU

2026-06-19T11:42:38+00:00

commit ec7216f92e4ebd485b1c6dc6aa3f6064b71a5768 upstream. NVIDIA Olympus cores are affected by the TLBI completion issue tracked as CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses ARM64_WORKAROUND_REPEAT_TLBI to issue an additional broadcast TLBI;DSB sequence and ensure affected memory write effects are globally observed. Add MIDR_NVIDIA_OLYMPUS to the repeat-TLBI match list so the same mitigation is enabled on affected Olympus systems. Also document the NVIDIA Olympus erratum in the arm64 silicon errata table and list it in the Kconfig help text. Signed-off-by: Shanker Donthineni Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Rutland Acked-by: Mark Rutland Signed-off-by: Will Deacon [Mark: backport to v6.12.y] Signed-off-by: Shanker Donthineni Signed-off-by: Greg Kroah-Hartman

arm64: errata: Mitigate TLBI errata on various Arm CPUs

2026-06-19T11:42:38+00:00

commit cfd391e74134db664feb499d43af286380b10ba8 upstream. A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number. Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Will Deacon [Mark: backport to v6.12.y] Signed-off-by: Mark Rutland Signed-off-by: Greg Kroah-Hartman

arm64: errata: Apply workarounds for Neoverse-V3AE

2025-10-23T14:20:47+00:00

commit 0c33aa1804d101c11ba1992504f17a42233f0e11 upstream. Neoverse-V3AE is also affected by erratum #3312417, as described in its Software Developer Errata Notice (SDEN) document: Neoverse V3AE (MP172) SDEN v9.0, erratum 3312417 https://developer.arm.com/documentation/SDEN-2615521/9-0/ Enable the workaround for Neoverse-V3AE, and document this. Signed-off-by: Mark Rutland Cc: James Morse Cc: Will Deacon Cc: Catalin Marinas Signed-off-by: Ryan Roberts Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman

x86/bugs: Rename MDS machinery to something more generic

2025-07-10T14:05:14+00:00

Commit f9af88a3d384c8b55beb5dc5483e5da0135fadbd upstream. It will be used by other x86 mitigations. No functional changes. Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Pawan Gupta Signed-off-by: Greg Kroah-Hartman

arm64/boot: Enable EL2 requirements for FEAT_PMUv3p9

2025-04-25T08:48:04+00:00

commit 858c7bfcb35e1100b58bb63c9f562d86e09418d9 upstream. FEAT_PMUv3p9 registers such as PMICNTR_EL0, PMICFILTR_EL0, and PMUACR_EL1 access from EL1 requires appropriate EL2 fine grained trap configuration via FEAT_FGT2 based trap control registers HDFGRTR2_EL2 and HDFGWTR2_EL2. Otherwise such register accesses will result in traps into EL2. Add a new helper __init_el2_fgt2() which initializes FEAT_FGT2 based fine grained trap control registers HDFGRTR2_EL2 and HDFGWTR2_EL2 (setting the bits nPMICNTR_EL0, nPMICFILTR_EL0 and nPMUACR_EL1) to enable access into PMICNTR_EL0, PMICFILTR_EL0, and PMUACR_EL1 registers. Also update booting.rst with SCR_EL3.FGTEn2 requirement for all FEAT_FGT2 based registers to be accessible in EL2. Cc: Will Deacon Cc: Mark Rutland Cc: Rob Herring Cc: Jonathan Corbet Cc: Marc Zyngier Cc: Oliver Upton Cc: linux-arm-kernel@lists.infradead.org Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: kvmarm@lists.linux.dev Fixes: 0bbff9ed8165 ("perf/arm_pmuv3: Add PMUv3.9 per counter EL0 access control") Fixes: d8226d8cfbaf ("perf: arm_pmuv3: Add support for Armv9.4 PMU instruction counter") Tested-by: Rob Herring (Arm) Reviewed-by: Rob Herring (Arm) Signed-off-by: Anshuman Khandual Link: https://lore.kernel.org/r/20250227035119.2025171-1-anshuman.khandual@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Anshuman Khandual Signed-off-by: Greg Kroah-Hartman

arm64: Filter out SVE hwcaps when FEAT_SVE isn't implemented

2025-02-17T09:05:04+00:00

commit 064737920bdbca86df91b96aed256e88018fef3a upstream. The hwcaps code that exposes SVE features to userspace only considers ID_AA64ZFR0_EL1, while this is only valid when ID_AA64PFR0_EL1.SVE advertises that SVE is actually supported. The expectations are that when ID_AA64PFR0_EL1.SVE is 0, the ID_AA64ZFR0_EL1 register is also 0. So far, so good. Things become a bit more interesting if the HW implements SME. In this case, a few ID_AA64ZFR0_EL1 fields indicate *SME* features. And these fields overlap with their SVE interpretations. But the architecture says that the SME and SVE feature sets must match, so we're still hunky-dory. This goes wrong if the HW implements SME, but not SVE. In this case, we end-up advertising some SVE features to userspace, even if the HW has none. That's because we never consider whether SVE is actually implemented. Oh well. Fix it by restricting all SVE capabilities to ID_AA64PFR0_EL1.SVE being non-zero. The HWCAPS documentation is amended to reflect the actually checks performed by the kernel. Fixes: 06a916feca2b ("arm64: Expose SVE2 features for userspace") Reported-by: Catalin Marinas Signed-off-by: Marc Zyngier Signed-off-by: Mark Brown Cc: Will Deacon Cc: Mark Rutland Cc: stable@vger.kernel.org Reviewed-by: Mark Brown Link: https://lore.kernel.org/r/20250107-arm64-2024-dpisa-v5-1-7578da51fc3d@kernel.org Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman

ACPI/IORT: Add PMCG platform information for HiSilicon HIP09A

2025-01-02T09:34:20+00:00

[ Upstream commit c2b46ae022704a2d845e59461fa24431ad627022 ] HiSilicon HIP09A platforms using the same SMMU PMCG with HIP09 and thus suffers the same erratum. List them in the PMCG platform information list without introducing a new SMMU PMCG Model. Update the silicon-errata.rst as well. Reviewed-by: Yicong Yang Acked-by: Hanjun Guo Signed-off-by: Qinxin Xia Link: https://lore.kernel.org/r/20241205013331.1484017-1-xiaqinxin@huawei.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin

irqchip/gicv3-its: Add workaround for hip09 ITS erratum 162100801

2024-12-14T19:04:09+00:00

[ Upstream commit f82e62d470cc990ebd9d691f931dd418e4e9cea9 ] When enabling GICv4.1 in hip09, VMAPP fails to clear some caches during the unmap operation, which can causes vSGIs to be lost. To fix the issue, invalidate the related vPE cache through GICR_INVALLR after VMOVP. Suggested-by: Marc Zyngier Co-developed-by: Nianyao Tang Signed-off-by: Nianyao Tang Signed-off-by: Zhou Wang Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Signed-off-by: Sasha Levin

x86/Documentation: Update algo in init_size description of boot protocol

2024-12-05T13:03:07+00:00

[ Upstream commit be4ca6c53e66cb275cf0d71f32dac0c4606b9dc0 ] The init_size description of boot protocol has an example of the runtime start address for the compressed bzImage. For non-relocatable kernel it relies on the pref_address value (if not 0), but for relocatable case only pays respect to the load_addres and kernel_alignment, and it is inaccurate for the latter. Boot loader must consider the pref_address as the Linux kernel relocates to it before being decompressed as nicely described in this commit message a year ago: 43b1d3e68ee7 ("kexec: Allocate kernel above bzImage's pref_address") Due to this documentation inaccuracy some of the bootloaders (*) made a mistake in the calculations and if kernel image is big enough, this may lead to unbootable configurations. *) In particular, kexec-tools missed that and resently got a couple of changes which will be part of v2.0.30 release. For the record, commit 43b1d3e68ee7 only fixed the kernel kexec implementation and also missed to update the init_size description. While at it, make an example C-like looking as it's done elsewhere in the document and fix indentation as presribed by the reStructuredText specifications, so the syntax highliting will work properly. Fixes: 43b1d3e68ee7 ("kexec: Allocate kernel above bzImage's pref_address") Fixes: d297366ba692 ("x86: document new bzImage fields") Signed-off-by: Andy Shevchenko Signed-off-by: Ingo Molnar Acked-by: Randy Dunlap Cc: "H. Peter Anvin" Link: https://lore.kernel.org/r/20241125105005.1616154-1-andriy.shevchenko@linux.intel.com Signed-off-by: Sasha Levin