summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2025-07-17arm64: Mark kernel as tainted on SAE and SError panicBreno Leitao2-0/+2
Set TAINT_MACHINE_CHECK when SError or Synchronous External Abort (SEA) interrupts trigger a panic to flag potential hardware faults. This tainting mechanism aids in debugging and enables correlation of hardware-related crashes in large-scale deployments. This change aligns with similar patches[1] that mark machine check events when the system crashes due to hardware errors. Link: https://lore.kernel.org/all/20250702-add_tain-v1-1-9187b10914b9@debian.org/ [1] Signed-off-by: Breno Leitao <leitao@debian.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20250716-vmcore_hw_error-v2-1-f187f7d62aba@debian.org Signed-off-by: Will Deacon <will@kernel.org>
2025-07-17arm64: dts: rockchip: Add maskrom button to NanoPi R5S + R5CDiederik de Haas1-0/+14
Both the R5S and R5C have a MASKROM button connected via saradc. For both the R5S as the R5C it's described on page 9 of their respective schematic, identified as 'Recovery'. Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Link: https://lore.kernel.org/r/20250716083355.327451-1-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-17s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL againIlya Leoshkevich1-1/+9
Commit 7ded842b356d ("s390/bpf: Fix bpf_plt pointer arithmetic") has accidentally removed the critical piece of commit c730fce7c70c ("s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL"), causing intermittent kernel panics in e.g. perf's on_switch() prog to reappear. Restore the fix and add a comment. Fixes: 7ded842b356d ("s390/bpf: Fix bpf_plt pointer arithmetic") Cc: stable@vger.kernel.org Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Link: https://lore.kernel.org/r/20250716194524.48109-2-iii@linux.ibm.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-07-17bpf, arm64: remove structs on stack constraintAlexis Lothoré (eBPF Foundation)1-5/+0
While introducing support for 9+ arguments for tracing programs on ARM64, commit 9014cf56f13d ("bpf, arm64: Support up to 12 function arguments") has also introduced a constraint preventing BPF trampolines from being generated if the target function consumes a struct argument passed on stack, because of uncertainties around the exact struct location: if the struct has been marked as packed or with a custom alignment, this info is not reflected in BTF data, and so generated tracing trampolines could read the target function arguments at wrong offsets. This issue is not specific to ARM64: there has been an attempt (see [1]) to bring the same constraint to other architectures JIT compilers. But discussions following this attempt led to the move of this constraint out of the kernel (see [2]): instead of preventing the kernel from generating trampolines for those functions consuming structs on stack, it is simpler to just make sure that those functions with uncertain struct arguments location are not encoded in BTF information, and so that one can not even attempt to attach a tracing program to such function. The task is then deferred to pahole (see [3]). Now that the constraint is handled by pahole, remove it from the arm64 JIT compiler to keep it simple. [1] https://lore.kernel.org/bpf/20250613-deny_trampoline_structs_on_stack-v1-0-5be9211768c3@bootlin.com/ [2] https://lore.kernel.org/bpf/CAADnVQ+sj9XhscN9PdmTzjVa7Eif21noAUH3y1K6x5bWcL-5pg@mail.gmail.com/ [3] https://lore.kernel.org/bpf/20250707-btf_skip_structs_on_stack-v3-0-29569e086c12@bootlin.com/ Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com> Link: https://lore.kernel.org/r/20250709-arm64_relax_jit_comp-v1-1-3850fe189092@bootlin.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-07-16MIPS: mm: tlb-r4k: Uniquify TLB entries on initJiaxun Yang1-1/+55
Hardware or bootloader will initialize TLB entries to any value, which may collide with kernel's UNIQUE_ENTRYHI value. On MIPS microAptiv/M5150 family of cores this will trigger machine check exception and cause boot failure. On M5150 simulation this could happen 7 times out of 1000 boots. Replace local_flush_tlb_all() with r4k_tlb_uniquify() which probes each TLB ENTRIHI unique value for collisions before it's written, and in case of collision try a different ASID. Cc: stable@kernel.org Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-07-16riscv: uaccess: Fix -Wuninitialized and -Wshadow in __put_user_nocheckNathan Chancellor1-2/+2
After a recent change in clang to strengthen uninitialized warnings [1], there is a warning from val being uninitialized in __put_user_nocheck when called from futex_put_value(): kernel/futex/futex.h:326:18: warning: variable 'val' is uninitialized when used within its own initialization [-Wuninitialized] 326 | unsafe_put_user(val, to, Efault); | ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~ arch/riscv/include/asm/uaccess.h:464:21: note: expanded from macro 'unsafe_put_user' 464 | __put_user_nocheck(x, (ptr), label) | ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~ arch/riscv/include/asm/uaccess.h:314:36: note: expanded from macro '__put_user_nocheck' 314 | __inttype(x) val = (__inttype(x))x; \ | ~~~ ^ While not on by default, -Wshadow flags the same mistake: kernel/futex/futex.h:326:2: warning: declaration shadows a local variable [-Wshadow] 326 | unsafe_put_user(val, to, Efault); | ^ arch/riscv/include/asm/uaccess.h:464:2: note: expanded from macro 'unsafe_put_user' 464 | __put_user_nocheck(x, (ptr), label) | ^ arch/riscv/include/asm/uaccess.h:314:16: note: expanded from macro '__put_user_nocheck' 314 | __inttype(x) val = (__inttype(x))x; \ | ^ kernel/futex/futex.h:320:48: note: previous declaration is here 320 | static __always_inline int futex_put_value(u32 val, u32 __user *to) | ^ Use a three underscore prefix for the val variable in __put_user_nocheck to avoid clashing with either val or __val, which are both used within the put_user macros, clearing up all warnings. Closes: https://github.com/ClangBuiltLinux/linux/issues/2109 Fixes: ca1a66cdd685 ("riscv: uaccess: do not do misaligned accesses in get/put_user()") Link: https://github.com/llvm/llvm-project/commit/2464313eef01c5b1edf0eccf57a32cdee01472c7 [1] Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20250715-riscv-uaccess-fix-self-init-val-v1-1-82b8e911f120@kernel.org Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-07-16MIPS: SGI-IP27: Delete an unnecessary check before kfree() in hub_domain_free()Markus Elfring1-1/+1
It can be known that the function “kfree” performs a null pointer check for its input parameter. It is therefore not needed to repeat such a check before its call. Thus remove a redundant pointer check. The source code was transformed by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-07-16mips/malta,loongson2ef: use generic mc146818_get_time functionMateusz Jończyk2-27/+9
mc146818_get_cmos_time() is now mostly equivalent to mc146818_get_time() from drivers/rtc/rtc-mc146818-lib.c, with the latter using a more advanced algorithm (which checks the UIP bit in the CMOS). The Malta and Loongson2ef platforms, the only users of mc146818_get_cmos_time() have RTC devices that should be MC146818 compatible. So, rewrite mc146818_get_cmos_time() in a way that uses mc146818_get_time() and add CONFIG_RTC_MC146818_LIB as a dependency of CONFIG_MIPS_MALTA and CONFIG_CPU_LOONGSON2EF. The should be safe as: - malta_defconfig already uses a standard RTC CMOS driver (CONFIG_RTC_DRV_CMOS=y). The Malta board has an Intel 82371EB (PIIX4E) south bridge with the CMOS RTC, so should work correctly with the modification, - Loongson2e and 2f apparently use the VIA686B south bridge and the AMD CS5536 south bridge respectively (at least according to Kconfig). I have checked datasheets of both and these appear to be MC146818 software compatible. Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-07-16mips: remove redundant macro mc146818_decode_yearMateusz Jończyk4-9/+4
The mc146818_decode_year macro is used only in mc146818_get_cmos_time(), which in turn is called only in arch/mips/loongson2ef/common/time.c and arch/mips/mti-malta/malta-time.c so on mach-jazz it is unused and can be removed. On other platforms it is defined in the same way, so it can be safely folded into mc146818_get_cmos_time(). Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-07-16mips/mach-rm: remove custom mc146818rtc.h fileMateusz Jończyk1-21/+0
The mc146818_decode_year macro is used only in mc146818_get_cmos_time, which in turn is called only in arch/mips/loongson2ef/common/time.c and arch/mips/mti-malta/malta-time.c So no SNI or mach-rm content. SNI did not use mc146818_get_cmos_time apparently since commit 06cf5583fd9a ("[MIPS] SNI RM updates") in 2007. Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-07-16mips: remove unused function mc146818_set_rtc_mmssMateusz Jończyk1-74/+0
I have checked carefully: this function is unused, so remove it. The last caller appears to have been removed in 2007 in commit 4b550488f894 ("[MIPS] Deforest the function pointer jungle in the time code.") mc146818-time.h is included only in three files: - arch/mips/mti-malta/malta-time.c - arch/mips/loongson64/numa.c - arch/mips/loongson2ef/common/time.c Also, remove unused macros USEC_AFTER/USEC_BEFORE. Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-07-16MIPS: CPS: Optimise delay CPU calibration for SMPGregory CLEMENT1-0/+11
On MIPS architecture with CPS-based SMP support, all CPU cores in the same cluster run at the same frequency since they share the same L2 cache, requiring a fixed CPU/L2 cache ratio. This allows to implement calibrate_delay_is_known(), which will return 0 (triggering calibration) only for the primary CPU of each cluster. For other CPUs, we can simply reuse the value from their cluster's primary CPU core. With the introduction of this patch, a configuration running 32 cores spread across two clusters sees a significant reduction in boot time by approximately 600 milliseconds. Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-07-16MIPS: CPS: Improve mips_cps_first_online_in_cluster()Gregory CLEMENT4-33/+24
The initial implementation of this function goes through all the CPUs in a cluster to determine if the current CPU is the only one running. This process occurs every time the function is called. However, during boot, we already perform this task, so let's take advantage of this opportunity to create and fill a CPU bitmask that can be easily and efficiently used later. This patch modifies the function to allow providing the first available online CPU when one already exists, which is necessary for delay CPU calibration optimization. Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-07-16MIPS: disable MMID when not supported by the hardwareGregory CLEMENT3-2/+46
It is possible that MMID is supported at the CPU level, but its integration in a SoC prevents its usage. For instance, if the System-level Interconnect (also known as Network on Chip) does not support global invalidation, then the MMID feature is not usable. The current implementation of MMID relies on the GINV* instructions. This patch allows the disabling of MMID based on a device tree property, as this issue cannot be detected at runtime. MMID is set up very early during the boot process, even before device tree data can be accessed. Therefore, when we determine whether MMID needs to be disabled, some MMID setup has already been performed for the boot CPU. Consequently, we must revert the MMID setup on the first CPU before disabling the feature for the subsequent CPUs that will be initialized later. Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-07-16MIPS: eyeq5_defconfig: add I2C subsystem, driver and temp sensor driverThéo Lebrun1-0/+4
Enable I2C support on the EyeQ5 platform. The evaluation board has a temperature sensor mounted which helps test the integration. Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-07-16MIPS: eyeq5_defconfig: add GPIO subsystem & driverThéo Lebrun1-0/+2
Enable GPIO support on the EyeQ5 platform. Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-07-16MIPS: mobileye: eyeq5: add two GPIO bank nodesThéo Lebrun1-0/+30
This platform uses the same GPIO controller as Nomadik. It however has its own pinconf & pinmux controller. EyeQ5 is the first platform to use gpio-nomadik independently from pinctrl-nomadik. Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-07-16MIPS: mobileye: eyeq5: add evaluation board I2C temp sensorThéo Lebrun1-0/+8
Declare the temperature sensor on I2C bus 2. Its label is the schematics identifier. Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-07-16MIPS: mobileye: eyeq5: add 5 I2C controller nodesThéo Lebrun1-0/+75
Add the SoC I2C controller nodes to the platform devicetree. Use a default bus frequency of 400kHz. They are AMBA devices that are matched on PeriphID. Set transfer timeout to 10ms instead of Linux's default of 200ms. Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-07-16MIPS: eyeq5_defconfig: Update for v6.16-rc1Théo Lebrun1-3/+1
- Sort by moving CONFIG_PAGE_SIZE_16KB=y. - Drop CONFIG_MACH_EYEQ5=y because it is the default: # arch/mips/mobileye/Kconfig choice prompt "Mobileye EyeQ SoC selection" default MACH_EYEQ5 - Drop CONFIG_SPARSEMEM_MANUAL=y because: # mm/Kconfig choice prompt "Memory model" depends on SELECT_MEMORY_MODEL default SPARSEMEM_MANUAL if ARCH_SPARSEMEM_DEFAULT default FLATMEM_MANUAL # arch/mips/Kconfig config EYEQ select ARCH_SPARSEMEM_DEFAULT if 64BIT Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-07-16MIPS: vpe-mt: add missing prototypes for vpe_{alloc,start,stop,free}Shiji Yang1-0/+8
These functions are exported but their prototypes are not defined. This patch adds the missing function prototypes to fix the following compilation warnings: arch/mips/kernel/vpe-mt.c:180:7: error: no previous prototype for 'vpe_alloc' [-Werror=missing-prototypes] 180 | void *vpe_alloc(void) | ^~~~~~~~~ arch/mips/kernel/vpe-mt.c:198:5: error: no previous prototype for 'vpe_start' [-Werror=missing-prototypes] 198 | int vpe_start(void *vpe, unsigned long start) | ^~~~~~~~~ arch/mips/kernel/vpe-mt.c:208:5: error: no previous prototype for 'vpe_stop' [-Werror=missing-prototypes] 208 | int vpe_stop(void *vpe) | ^~~~~~~~ arch/mips/kernel/vpe-mt.c:229:5: error: no previous prototype for 'vpe_free' [-Werror=missing-prototypes] 229 | int vpe_free(void *vpe) | ^~~~~~~~ Signed-off-by: Shiji Yang <yangshiji66@outlook.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-07-16riscv: Stop supporting static ftraceAlexandre Ghiti1-1/+2
Now that DYNAMIC_FTRACE was introduced, there is no need to support static ftrace as it is way less performant. This simplifies the code and prevents build failures as reported by kernel test robot when !DYNAMIC_FTRACE. Also make sure that FUNCTION_TRACER can only be selected if DYNAMIC_FTRACE is supported (we have a dependency on the toolchain). Co-developed-by: chenmiao <chenmiao.ku@gmail.com> Signed-off-by: chenmiao <chenmiao.ku@gmail.com> Fixes: b2137c3b6d7a ("riscv: ftrace: prepare ftrace for atomic code patching") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202506191949.o3SMu8Zn-lkp@intel.com/ Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250716-dev-alex-static_ftrace-v1-1-ba5d2b6fc9c0@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-07-16riscv: traps_misaligned: properly sign extend value in misaligned load handlerAndreas Schwab1-1/+1
Add missing cast to signed long. Signed-off-by: Andreas Schwab <schwab@suse.de> Fixes: 956d705dd279 ("riscv: Unaligned load/store handling for M_MODE") Tested-by: Clément Léger <cleger@rivosinc.com> Link: https://lore.kernel.org/r/mvmikk0goil.fsf@suse.de Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-07-16riscv: Enable interrupt during exception handlingNam Cao1-4/+6
force_sig_fault() takes a spinlock, which is a sleeping lock with CONFIG_PREEMPT_RT=y. However, exception handling calls force_sig_fault() with interrupt disabled, causing a sleeping in atomic context warning. This can be reproduced using userspace programs such as: int main() { asm ("ebreak"); } or int main() { asm ("unimp"); } There is no reason that interrupt must be disabled while handling exceptions from userspace. Enable interrupt while handling user exceptions. This also has the added benefit of avoiding unnecessary delays in interrupt handling. Fixes: f0bddf50586d ("riscv: entry: Convert to generic entry") Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250625085630.3649485-1-namcao@linutronix.de Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-07-16riscv: dts: starfive: jh7110-common: add status power led nodeE Shattow1-0/+9
Add status power led node for StarFive VisionFive2 and variant boards. Signed-off-by: E Shattow <e@freeshell.de> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-07-16riscv: dts: starfive: jh7110-milkv-mars sort propertiesE Shattow1-6/+6
Improve style with node property order sort of common properties before vendor prefixes Signed-off-by: E Shattow <e@freeshell.de> Acked-by: Emil Renner Berthing <emil.renner.berthing@canonical.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-07-16riscv: ftrace: Properly acquire text_mutex to fix a race conditionAlexandre Ghiti1-4/+14
As reported by lockdep, some patching was done without acquiring text_mutex, so there could be a race when mapping the page to patch since we use the same fixmap entry. Reported-by: Han Gao <rabenda.cn@gmail.com> Reported-by: Vivian Wang <wangruikang@iscas.ac.cn> Reported-by: Yao Zi <ziyao@disroot.org> Closes: https://lore.kernel.org/linux-riscv/aGODMpq7TGINddzM@pie.lan/ Tested-by: Yao Zi <ziyao@disroot.org> Tested-by: Han Gao <rabenda.cn@gmail.com> Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250711-alex-fixes-v2-1-d85a5438da6c@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-07-16riscv: Stop considering R_RISCV_NONE as bad relocationsAlexandre Ghiti1-1/+3
Even though those relocations should not be present in the final vmlinux, there are a lot of them. And since those relocations are considered "bad", they flood the compilation output which may hide some legitimate bad relocations. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Tested-by: Ron Economos <re@w6rz.net> Link: https://lore.kernel.org/r/20250710-dev-alex-riscv_none_bad_relocs_v1-v1-1-758f2fcc6e75@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-07-16arm64: cacheinfo: Provide helper to compress MPIDR value into u32James Morse1-0/+17
Filesystems like resctrl use the cache-id exposed via sysfs to identify groups of CPUs. The value is also used for PCIe cache steering tags. On DT platforms cache-id is not something that is described in the device-tree, but instead generated from the smallest MPIDR of the CPUs associated with that cache. The cache-id exposed to user-space has historically been 32 bits. MPIDR values may be larger than 32 bits. MPIDR only has 32 bits worth of affinity data, but the aff3 field lives above 32bits. The corresponding lower bits are masked out by MPIDR_HWID_BITMASK and contain an SMT flag and Uni-Processor flag. Swizzzle the aff3 field into the bottom 32 bits and using that. In case more affinity fields are added in the future, the upper RES0 area should be checked. Returning a value greater than 32 bits from this helper will cause the caller to give up on allocating cache-ids. Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Link: https://lore.kernel.org/r/20250711182743.30141-4-james.morse@arm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-16s390/pai_crypto: Rename PAI Crypto event 4210Thomas Richter1-1/+1
The PAI crypto event number 4210 is named PCC_COMPUTE_LAST_BLOCK_CMAC_USING_ENCRYPTED_AES_256A According to the z16 and z17 Principle of Operation documents SA22-7832-13 and SA22-7832-14 the event is named PCC_COMPUTE_LAST_BLOCK_CMAC_USING_ENCRYPTED_AES_256 without a trailing 'A'. Adjust this event name. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Reviewed-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2025-07-16KVM: arm64: Tighten the definition of FEAT_PMUv3p9Marc Zyngier1-3/+7
The current definition of FEAT_PMUv3p9 doesn't check for the lack of an IMPDEF PMU, which is encoded as 0b1111, but considered unsigned. Use the recently introduced helper to address the issue (which is harmless, as KVM never advertises an IMPDEF PMU). Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714115503.3334242-6-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-16KVM: arm64: Convert MDCR_EL2 to config-driven sanitisationMarc Zyngier2-34/+64
As for other registers, convert the determination of the RES0 bits affecting MDCR_EL2 to be driven by a table extracted from the 2025-06 JSON drop Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714115503.3334242-5-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-16KVM: arm64: Convert SCTLR_EL1 to config-driven sanitisationMarc Zyngier2-4/+107
As for other registers, convert the determination of the RES0 bits affecting SCTLR_EL1 to be driven by a table extracted from the 2025-06 JSON drop Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714115503.3334242-4-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-16KVM: arm64: Convert TCR2_EL2 to config-driven sanitisationMarc Zyngier2-19/+49
As for other registers, convert the determination of the RES0 bits affecting TCR2_EL2 to be driven by a table extracted from the 2025-06 JSON drop. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714115503.3334242-3-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-16arm64: sysreg: Add THE/ASID2 controls to TCR2_ELxMarc Zyngier1-2/+11
FEAT_THE and FEAT_ASID2 add new controls to the TCR2_ELx registers. Add them to the register descriptions. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714115503.3334242-2-maz@kernel.org [ fix whitespace ] Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-16KVM: arm64: Advertise FGT2 registers to userspaceMarc Zyngier1-0/+15
While a guest is able to use the FEAT_FGT2 registers, we're missing them being exposed to userspace. Add them to the (very long) list. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714122634.3334816-9-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-16KVM: arm64: Condition FGT registers on feature availabilityMarc Zyngier1-5/+15
We shouldn't expose the FEAT_FGT registers unconditionally. Make them dependent on FEAT_FGT being actually advertised to the guest. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714122634.3334816-8-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-16KVM: arm64: Expose GICv3 EL2 registers via KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGSMarc Zyngier1-0/+113
Expose all the GICv3 EL2 registers through the usual GICv3 save/restore interface, making it possible for a VMM to access the EL2 state. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714122634.3334816-7-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-16KVM: arm64: Let GICv3 save/restore honor visibility attributeMarc Zyngier1-2/+6
The GICv3 save/restore code never needed any visibility attribute, but that's about to change. Make vgic_v3_has_cpu_sysregs_attr() check the visibility in case a register is hidden. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714122634.3334816-6-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-16KVM: arm64: Define helper for ICH_VTR_EL2Marc Zyngier2-5/+16
Move the computation of the ICH_VTR_EL2 value to a common location, so that it can be reused by the save/restore code. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714122634.3334816-5-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-16KVM: arm64: Define constant value for ICC_SRE_EL2Marc Zyngier2-2/+4
Move the bag of bits defining the value of ICC_SRE_EL2 to a common spot so that it can be reused by the save/restore code. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714122634.3334816-4-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-16KVM: arm64: Don't advertise ICH_*_EL2 registers through GET_ONE_REGMarc Zyngier1-27/+37
It appears that exposing the GICv3 EL2 registers through the usual sysreg interface is not consistent with the way we expose the EL1 registers. The latter are exposed via the GICv3 device interface instead, and there is no reason why the EL2 registers should get a different treatement. Hide the registers from userspace until the GICv3 code grows the required infrastructure. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714122634.3334816-3-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-16KVM: arm64: Make RVBAR_EL2 accesses UNDEFMarc Zyngier1-2/+1
We always expose a virtual CPU that has EL3 when NV is enabled, irrespective of EL3 being actually implemented in HW. Therefore, as per the architecture, RVBAR_EL2 must UNDEF, since EL2 is not the highest implemented exception level. This is consistent with RMR_EL2 also triggering an UNDEF. Adjust the handling of RVBAR_EL2 accordingly. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714122634.3334816-2-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-16KVM: arm64: Commit exceptions from KVM_SET_VCPU_EVENTS immediatelyOliver Upton1-1/+27
syzkaller has found that it can trip a warning in KVM's exception emulation infrastructure by repeatedly injecting exceptions into the guest. While it's unlikely that a reasonable VMM will do this, further investigation of the issue reveals that KVM can potentially discard the "pending" SEA state. While the handling of KVM_GET_VCPU_EVENTS presumes that userspace-injected SEAs are realized immediately, in reality the emulated exception entry is deferred until the next call to KVM_RUN. Hack-a-fix the immediate issues by committing the pending exceptions to the vCPU's architectural state immediately in KVM_SET_VCPU_EVENTS. This is no different to the way KVM-injected exceptions are handled in KVM_RUN where we potentially call __kvm_adjust_pc() before returning to userspace. Reported-by: syzbot+4e09b1432de3774b86ae@syzkaller.appspotmail.com Reported-by: syzbot+1f6f096afda6f4f8f565@syzkaller.appspotmail.com Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-16KVM: VMX: Ensure unused kvm_tdx_capabilities fields are zeroed outSean Christopherson1-3/+4
Zero-allocate the kernel's kvm_tdx_capabilities structure and copy only the number of CPUID entries from the userspace structure. As is, KVM doesn't ensure kernel_tdvmcallinfo_1_{r11,r12} and user_tdvmcallinfo_1_r12 are zeroed, i.e. KVM will reflect whatever happens to be in the userspace structure back at userspace, and thus may report garbage to userspace. Zeroing the entire kernel structure also provides better semantics for the reserved field. E.g. if KVM extends kvm_tdx_capabilities to enumerate new information by repurposing bytes from the reserved field, userspace would be required to zero the new field in order to get useful information back (because older KVMs without support for the repurposed field would report garbage, a la the aforementioned tdvmcallinfo bugs). Fixes: 61bb28279623 ("KVM: TDX: Get system-wide info about TDX module on initialization") Suggested-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Reported-by: Xiaoyao Li <xiaoyao.li@intel.com> Closes: https://lore.kernel.org/all/3ef581f1-1ff1-4b99-b216-b316f6415318@intel.com Tested-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Link: https://lore.kernel.org/r/20250714221928.1788095-1-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-07-15arm64: dts: rockchip: Drop regulator-compatible property on rk3399Diederik de Haas2-4/+0
The regulator-compatible property has never existed in the regulator/fcs,fan53555.yaml binding, so drop it. This fixes the following DTB validation warnings: Unevaluated properties are not allowed ('regulator-compatible' was unexpected) Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Link: https://lore.kernel.org/r/20250709132323.128757-11-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-15arm64: dts: rockchip: Drop unneeded address+size-cells on px30Diederik de Haas1-4/+0
On nodes with compatible "rockchip,px30-usb2phy-grf", the #address-cells and #size-cells are required and consequently their child nodes should have unit addresses. That is not the case for the px30-pmugrf and px30-grf nodes, so remove them there. This fixes the following DTB validation warnings: unnecessary #address-cells/#size-cells without "ranges", "dma-ranges" or child "reg" property Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Link: https://lore.kernel.org/r/20250709132323.128757-10-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-15arm64: dts: rockchip: Fix LCD panel port on rk3566-pinetab2Diederik de Haas1-3/+3
The MIPI DSI connector on the PineTab2 only has 1 port with 1 endpoint, so drop the unit-address properties. While at it, move 'rotation' property to its proper sorting position. This fixes the following DTB validation warnings: node has a unit name, but no reg or ranges property Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Link: https://lore.kernel.org/r/20250709132323.128757-9-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-15arm64: dts: rockchip: Move mipi_out node on rk3399 haikou demo dtsoDiederik de Haas1-6/+6
According to the DTS coding style [1] referenced nodes should be sorted alpha-numerically so move mipi_out to be after mipi_in_panel. [1] https://www.kernel.org/doc/html/latest/devicetree/bindings/dts-coding-style.html#order-of-nodes Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Link: https://lore.kernel.org/r/20250709132323.128757-8-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-15arm64: dts: rockchip: Simplify mipi_out endpoint on rk3399 RP64 dtsoDiederik de Haas1-13/+6
The only thing actually added here is a single endpoint on mipi_out, which is already defined in rk3399-base.dtsi, so it's simpler to just reference that phandle, which allows the removal of several properties. Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Link: https://lore.kernel.org/r/20250709132323.128757-7-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-12 03:52:45 +0300