kernel/linux.git/arch/arm64/include/uapi, branch v7.2-rc1

Merge tag 'arm64-upstream' of gitolite.kernel.org:pub/scm/linux/kernel/git/arm64/linux

2026-06-15T23:48:04+00:00

Pull arm64 updates from Will Deacon: "It feels like the new world of AI tooling has slowed us down a little on the feature side when compared to the fixes side. The extra rounds of Sashiko review have also pushed a few things out until next time. Still, there's some good foundational stuff here for the fpsimd code and hardening work towards removing the predictable linear alias of the kernel image. CPU errata handling: - Extend CnP disabling workaround to HiSilicon HIP09 hardware. - Work around eternally broken broadcast TLB invalidation on more CPUs. - Documentation and code cleanups. CPU features: - Add new hwcaps for the 2025 dpISA extensions. Floating point / SVE / SME: - Significant cleanup to the low-level state management code in the core architecture code and KVM. - Use correct register widths during SVE/SME save/restore assembly. - Expose SVE/SME save/restore memory accesses to sanitisers. Memory management: - Preparatory work for unmapping the kernel data and bss sections from the linear map. Miscellaneous: - Inline DAIF manipulation helpers so they can be used safely from non-instrumentable code. - Fix handling of the 'nosmp' cmdline option to avoid marking secondary cores as "possible". MPAM: - Add support for v0.1 of the MPAM architecture. Perf: - Update HiSilicon PMU MAINTAINERS entry. - Fix event encodings for the DVM node in the CMN driver. Selftests: - Extend sigframe tests to cover POE context. - Add coverage for the newly added 2025 dpISA hwcaps. System registers: - Add new registers and ESR encodings for the HDBSS feature. Plus minor fixes and cleanups across the board" * tag 'arm64-upstream' of gitolite.kernel.org:pub/scm/linux/kernel/git/arm64/linux: (73 commits) arm64: errata: Mitigate TLBI errata on Microsoft Azure Cobalt 100 CPU arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU arm64: errata: Mitigate TLBI errata on various Arm CPUs arm64: cputype: Add C1-Premium definitions arm64: cputype: Add C1-Ultra definitions Revert "arm64: mm: Unmap kernel data/bss entirely from the linear map" Revert "arm64: mm: Defer remap of linear alias of data/bss" arm64: arch_timer: reuse arch_timer_read_cnt{p,v}ct_el0() helpers arm64/mm: Rename ptdesc_t arm64: mm: Defer remap of linear alias of data/bss KVM: arm64: Omit tag sync on stage-2 mappings of the zero page arm64: Avoid double evaluation of __ptep_get() kasan: Move generic KASAN page tables out of BSS too arm64: Rename page table BSS section to .bss..pgtbl arm64: patching: replace min_t with min in __text_poke perf/arm-cmn: Fix DVM node events arm64: fpsimd: Remove arm64: fpsimd: Move SME save/restore inline arm64: fpsimd: Move sve_flush_live() inline arm64: fpsimd: Move SVE save/restore inline ...

vfs: uapi: retire octal and hex numbers in favor of (1 << n) for O_ flags

2026-06-06T13:34:03+00:00

A recent build failure[1] exposed the diffculty of working with the current octal and hex definitions of O_ flags when trying to find a gap for a new flag. This difficulty is compounded by the fact that O_ flags may have architectural specific values. Replace the hex/octal #defines, which are hard to parse when looking for free bits, with explicit bit shifts like (1 << 11). Also, add comments that identify which architectures redefine some of the seemingly free ("cursed") bits in uapi/asm-generic/fcntl.h. These should not be used to define new O_ flags (for now, at least). The translastion was done with Claude Opus 4.8, and verified with a (non-AI) gawk script. The accounting of which architectures claim which bit-gaps in uapi/asm-generic/fcntl.h is also done by hand. [1]: https://lore.kernel.org/all/agruPPybCx8q2XcJ@sirena.org.uk/ Assisted-by: Claude:Opus 4.8 Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260604222405.5382-1-jkoolstra@xs4all.nl Signed-off-by: Christian Brauner (Amutable)

arm64/cpufeature: Define hwcaps for 2025 dpISA features

2026-05-19T12:57:51+00:00

The features added by the 2025 dpISA are all straightforward instruction only features so there is no state to manage, we can just expose hwcaps to let userspace know they are available. F16MM is slightly odd in that the feature is FEAT_F16MM but it is discovered via ID_AA64FPFR0_EL1.F16MM2. We follow the feature name. Signed-off-by: Mark Brown Signed-off-by: Will Deacon

KVM: arm64: gic-v5: Communicate userspace-driveable PPIs via a UAPI

2026-03-19T18:21:29+00:00

GICv5 systems will likely not support the full set of PPIs. The presence of any virtual PPI is tied to the presence of the physical PPI. Therefore, the available PPIs will be limited by the physical host. Userspace cannot drive any PPIs that are not implemented. Moreover, it is not desirable to expose all PPIs to the guest in the first place, even if they are supported in hardware. Some devices, such as the arch timer, are implemented in KVM, and hence those PPIs shouldn't be driven by userspace, either. Provided a new UAPI: KVM_DEV_ARM_VGIC_GRP_CTRL => KVM_DEV_ARM_VGIC_USERPSPACE_PPIs This allows userspace to query which PPIs it is able to drive via KVM_IRQ_LINE. Additionally, introduce a check in kvm_vm_ioctl_irq_line() to reject any PPIs not in the userspace mask. Signed-off-by: Sascha Bischoff Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20260319154937.3619520-40-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

arm64: Add support for FEAT_{LS64, LS64_V}

2026-01-22T13:24:49+00:00

Armv8.7 introduces single-copy atomic 64-byte loads and stores instructions and its variants named under FEAT_{LS64, LS64_V}. These features are identified by ID_AA64ISAR1_EL1.LS64 and the use of such instructions in userspace (EL0) can be trapped. As st64bv (FEAT_LS64_V) and st64bv0 (FEAT_LS64_ACCDATA) can not be tell apart, FEAT_LS64 and FEAT_LS64_ACCDATA which will be supported in later patch will be exported to userspace, FEAT_LS64_V will be enabled only in kernel. In order to support the use of corresponding instructions in userspace: - Make ID_AA64ISAR1_EL1.LS64 visbile to userspace - Add identifying and enabling in the cpufeature list - Expose these support of these features to userspace through HWCAP3 and cpuinfo ld64b/st64b (FEAT_LS64) and st64bv (FEAT_LS64_V) is intended for special memory (device memory) so requires support by the CPU, system and target memory location (device that support these instructions). The HWCAP3_LS64, implies the support of CPU and system (since no identification method from system, so SoC vendors should advertise support in the CPU if system also support them). Otherwise for ld64b/st64b the atomicity may not be guaranteed or a DABT will be generated, so users (probably userspace driver developer) should make sure the target memory (device) also have the support. For st64bv 0xffffffffffffffff will be returned as status result for unsupported memory so user should check it. Document the restrictions along with HWCAP3_LS64. Acked-by: Arnd Bergmann Acked-by: Oliver Upton Signed-off-by: Yicong Yang Signed-off-by: Zhou Wang Signed-off-by: Will Deacon

arm64: Replace ASSEMBLY with ASSEMBLER in uapi headers

2025-11-11T19:35:58+00:00

__ASSEMBLY__ is only defined by the Makefile of the kernel, so this is not really useful for uapi headers (unless the userspace Makefile defines it, too). Let's switch to __ASSEMBLER__ which gets set automatically by the compiler when compiling assembly code. Signed-off-by: Thomas Huth Signed-off-by: Catalin Marinas

Merge branch 'for-next/cpufeature' into for-next/core

2025-09-24T15:33:53+00:00

* for-next/cpufeature: arm64: cpufeature: add Neoverse-V3AE to BBML2 allow list arm64: errata: Apply workarounds for Neoverse-V3AE arm64: cputype: Add Neoverse-V3AE definitions arm64: cpufeature: add AmpereOne to BBML2 allow list arm64: cpufeature: Add Olympus MIDR to BBML2 allow list arm64: cputype: Add NVIDIA Olympus definitions arm64: cputype: Remove duplicate Cortex-X1C definitions arm64: errata: Expand speculative SSBS workaround for Cortex-A720AE arm64: cputype: Add Cortex-A720AE definitions arm64/hwcap: Add hwcap for FEAT_LSFE

arm64/hwcap: Add hwcap for FEAT_LSFE

2025-09-16T18:55:11+00:00

FEAT_LSFE (Large System Float Extension), providing atomic floating point memory operations, is optional from v9.5. This feature adds no new architectural stare and we have no immediate use for it in the kernel so simply provide a hwcap for it to support discovery by userspace. Signed-off-by: Mark Brown Signed-off-by: Will Deacon

arm64: uapi: Provide correct __BITS_PER_LONG for the compat vDSO

2025-09-03T11:07:23+00:00

The generic vDSO library uses the UAPI headers. On arm64 __BITS_PER_LONG is always '64' even when used from the compat vDSO. In that case __GENMASK() does an illegal bitshift, invoking undefined behaviour. Change __BITS_PER_LONG to also work when used from the comapt vDSO. To not confuse real userspace, only do this when building the kernel. Reported-by: John Stultz Closes: https://lore.kernel.org/lkml/CANDhNCqvKOc9JgphQwr0eDyJiyG4oLFS9R8rSFvU0fpurrJFDg@mail.gmail.com/ Fixes: cd3557a7618b ("vdso/gettimeofday: Add support for auxiliary clocks") Signed-off-by: Thomas Weißschuh Acked-by: Arnd Bergmann Tested-by: John Stultz Link: https://lore.kernel.org/r/20250821-vdso-arm64-compat-bitsperlong-v1-1-700bcabe7732@linutronix.de Signed-off-by: Catalin Marinas

arm64/hwcaps: Add MTE_STORE_ONLY hwcaps

2025-07-02T17:49:04+00:00

Since ARMv8.9, FEAT_MTE_STORE_ONLY can be used to restrict raise of tag check fault on store operation only. add MTE_STORE_ONLY hwcaps so that user can use this feature. Signed-off-by: Yeoreum Yun Link: https://lore.kernel.org/r/20250618092957.2069907-5-yeoreum.yun@arm.com Signed-off-by: Catalin Marinas