summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2026-04-04riscv: add hardware error trap handler supportRui Qi
Add support for handling hardware error traps (exception code 19) in the RISC-V architecture. The changes include: - Add do_trap_hardware_error function declaration in asm-prototypes.h - Add hardware error trap vector entry in entry.S exception vector table - Implement do_trap_hardware_error handler in traps.c that generates SIGBUS with BUS_MCEERR_AR for hardware errors This enables proper handling of hardware error exceptions that may occur in RISC-V systems, providing appropriate error reporting and signal generation for user space processes. Signed-off-by: Rui Qi <qirui.001@bytedance.com> Link: https://patch.msgid.link/20260202094200.53735-1-qirui.001@bytedance.com [pjw@kernel.org: clean up commit message slightly] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04riscv: increase COMMAND_LINE_SIZE value to 2048Austin Kim
SoC people may send many parameters to configure the drivers via kernel command line. If COMMAND_LINE_SIZE is not enough, they may go through unexpected error. To avoid the potential pain, we had better increase COMMAND_LINE_SIZE. Signed-off-by: Austin Kim <austin.kim@lge.com> Link: https://patch.msgid.link/aW3gFmOlA/Z4kmfJ@adminpc-PowerEdge-R7525 Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04riscv: Fix typo in purgatory end labelZishun Yi
Fix the spelling of 'purgatory' in the .Lkexec_purgatroy_end label. Signed-off-by: Zishun Yi <vulab@iscas.ac.cn> Link: https://patch.msgid.link/20260325083139.15638-1-vulab@iscas.ac.cn Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04riscv: remove redundant #ifdef check in cpu-hotplugHui Wang
The cpu-hotplug.c only is built when CONFIG_HOTPLUG_CPU is defined, it is not needed to check HOTPLUG_CPU in this file. Signed-off-by: Hui Wang <hui.wang@canonical.com> Link: https://patch.msgid.link/20260304033403.238012-2-hui.wang@canonical.com [pjw@kernel.org: removed extra whitespace at EOF] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04riscv: remove redundant check for CONFIG_SMPHui Wang
In the arch/riscv/Kconfig, the HOTPLUG_CPU depends on SMP, hence if the HOTPLUG_CPU is defined, the SMP has to be defined, it is not necessary to check SMP here. Signed-off-by: Hui Wang <hui.wang@canonical.com> Link: https://patch.msgid.link/20260304033403.238012-1-hui.wang@canonical.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04riscv: Simplify assignment for UTS_MACHINEUwe Kleine-König
The BITS variable conveniently allows to simplify the assignment for UTS_MACHINE. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Link: https://patch.msgid.link/20260313164012.1153936-2-u.kleine-koenig@baylibre.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04riscv: export kaslr offset and satp in VMCOREINFO ELF notesAustin Kim
The following options are required by the kdump crash utility for RISC-V based vmcore file: - kaslr: If the vmcore is generated from a KASLR-enabled Linux kernel, the KASLR offset is required for the crash utility to load the vmcore. Without the proper kaslr option, the crash utility fails to load the vmcore file. - satp: The exact root page table address helps determine the correct base PGD address. With this patch, RISC-V VMCOREINFO ELF notes now include both kaslr and satp information. Signed-off-by: Austin Kim <austin.kim@lge.com> Link: https://patch.msgid.link/aYwKUE3ZzN7/ZY/A@adminpc-PowerEdge-R7525 Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04riscv: move kaslr_offset() to page.h as a static inline functionAustin Kim
The kaslr_offset() function is a simple accessor that returns kernel_map.virt_offset. This commit change also ensures that kaslr_offset() is consistently available across various kernel configurations without requiring explicit linkage to mm/init.c. Signed-off-by: Austin Kim <austin.kim@lge.com> Link: https://patch.msgid.link/aYwJ76yHaMbbQVJA@adminpc-PowerEdge-R7525 Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04riscv: smp: Clarify comment "cache" -> "instruction cache"Vivian Wang
local_flush_icache_all() only flushes and synchronizes the *instruction* cache, not the data cache. Since RISC-V does have a cbo.flush instruction for data cache flush, clarify the comment to avoid confusion. Fixes: 58661a30f1bc ("riscv: Flush the instruction cache during SMP bringup") Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://patch.msgid.link/20260204-riscv-smp-comment-update-2026-01-v1-2-8b77aa181530@iscas.ac.cn Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04riscv: smp: Remove outdated comment about disabling preemptionVivian Wang
Commit f1a0a376ca0c ("sched/core: Initialize the idle task with preemption disabled") removed a call to preempt_disable(), but not the associated comment. Remove the outdated comment. Fixes: f1a0a376ca0c ("sched/core: Initialize the idle task with preemption disabled") Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://patch.msgid.link/20260204-riscv-smp-comment-update-2026-01-v1-1-8b77aa181530@iscas.ac.cn Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04riscv: fix various typos in comments and codeSean Chang
Fix various typos in RISC-V architecture code and comments. The following changes are included: - arch/riscv/errata/thead/errata.c: "futher" → "further" - arch/riscv/include/asm/atomic.h: "therefor" → "therefore", "arithmatic" → "arithmetic" - arch/riscv/include/asm/elf.h: "availiable" → "available", "coorespends" → "corresponds" - arch/riscv/include/asm/processor.h: "requries" → "is required" - arch/riscv/include/asm/thread_info.h: "returing" → "returning" - arch/riscv/kernel/acpi.c: "compliancy" → "compliance" - arch/riscv/kernel/ftrace.c: "therefor" → "therefore" - arch/riscv/kernel/head.S: "intruction" → "instruction" - arch/riscv/kernel/mcount-dyn.S: "localtion → "location" - arch/riscv/kernel/module-sections.c: "maxinum" → "maximum" - arch/riscv/kernel/probes/kprobes.c: "reenabled" → "re-enabled" - arch/riscv/kernel/probes/uprobes.c: "probbed" → "probed" - arch/riscv/kernel/soc.c: "extremly" → "extremely" - arch/riscv/kernel/suspend.c: "incosistent" → "inconsistent" - arch/riscv/kvm/tlb.c: "cahce" → "cache" - arch/riscv/kvm/vcpu_pmu.c: "indicies" → "indices" - arch/riscv/lib/csum.c: "implmentations" → "implementations" - arch/riscv/lib/memmove.S: "ammount" → "amount" - arch/riscv/mm/cacheflush.c: "visable" → "visible" - arch/riscv/mm/physaddr.c: "aginst" → "against" Signed-off-by: Sean Chang <seanwascoding@gmail.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20260212163325.60389-1-seanwascoding@gmail.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04prctl: cfi: change the branch landing pad prctl()s to be more descriptivePaul Walmsley
Per Linus' comments requesting the replacement of "INDIR_BR_LP" in the indirect branch tracking prctl()s with something more readable, and suggesting the use of the speculation control prctl()s as an exemplar, reimplement the prctl()s and related constants that control per-task forward-edge control flow integrity. This primarily involves two changes. First, the prctls are restructured to resemble the style of the speculative execution workaround control prctls PR_{GET,SET}_SPECULATION_CTRL, to make them easier to extend in the future. Second, the "indir_br_lp" abbrevation is expanded to "branch_landing_pads" to be less telegraphic. The kselftest and documentation is adjusted accordingly. Link: https://lore.kernel.org/linux-riscv/CAHk-=whhSLGZAx3N5jJpb4GLFDqH_QvS07D+6BnkPWmCEzTAgw@mail.gmail.com/ Cc: Deepak Gupta <debug@rivosinc.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04riscv: ptrace: cfi: expand "SS" references to "shadow stack" in uapi headersPaul Walmsley
Similar to the recent change to expand "LP" to "branch landing pad", let's expand "SS" in the ptrace uapi macros to "shadow stack" as well. This aligns with the existing prctl() arguments, which use the expanded "shadow stack" names, rather than just the abbreviation. Link: https://lore.kernel.org/linux-riscv/CAHk-=whhSLGZAx3N5jJpb4GLFDqH_QvS07D+6BnkPWmCEzTAgw@mail.gmail.com/ Cc: Deepak Gupta <debug@rivosinc.com> Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04prctl: rename branch landing pad implementation functions to be more explicitPaul Walmsley
Per Linus' comments about the unreadability of abbreviations such as "indir_br_lp", rename the three prctl() implementation functions to be more explicit. This involves renaming "indir_br_lp_status" in the function names to "branch_landing_pad_state". While here, add _prctl_ into the function names, following the speculation control prctl implementation functions. Link: https://lore.kernel.org/linux-riscv/CAHk-=whhSLGZAx3N5jJpb4GLFDqH_QvS07D+6BnkPWmCEzTAgw@mail.gmail.com/ Cc: Deepak Gupta <debug@rivosinc.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04riscv: ptrace: expand "LP" references to "branch landing pads" in uapi headersPaul Walmsley
Per Linus' comments about the unreadability of abbreviations such as "LP", rename the RISC-V ptrace landing pad CFI macro names to be more explicit. This primarily involves expanding "LP" in the names to some variant of "branch landing pad." Link: https://lore.kernel.org/linux-riscv/CAHk-=whhSLGZAx3N5jJpb4GLFDqH_QvS07D+6BnkPWmCEzTAgw@mail.gmail.com/ Cc: Deepak Gupta <debug@rivosinc.com> Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04riscv: cfi: clear CFI lock status in start_thread()Zong Li
When libc locks the CFI status through the following prctl: - PR_LOCK_SHADOW_STACK_STATUS - PR_LOCK_INDIR_BR_LP_STATUS A newly execd address space will inherit the lock status if it does not clear the lock bits. Since the lock bits remain set, libc will later fail to enable the landing pad and shadow stack. Signed-off-by: Zong Li <zong.li@sifive.com> Link: https://patch.msgid.link/20260323065640.4045713-1-zong.li@sifive.com [pjw@kernel.org: ensure we unlock before changing state; cleaned up subject line] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04riscv: ptrace: cfi: fix "PRACE" typo in uapi headerPaul Walmsley
A CFI-related macro defined in arch/riscv/uapi/asm/ptrace.h misspells "PTRACE" as "PRACE"; fix this. Fixes: 2af7c9cf021c ("riscv/ptrace: expose riscv CFI status and state via ptrace and in core files") Cc: Deepak Gupta <debug@rivosinc.com> Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04riscv: use _BITUL macro rather than BIT() in ptrace uapi and kselftestsPaul Walmsley
Fix the build of non-kernel code that includes the RISC-V ptrace uapi header, and the RISC-V validate_v_ptrace.c kselftest, by using the _BITUL() macro rather than BIT(). BIT() is not available outside the kernel. Based on patches and comments from Charlie Jenkins, Michael Neuling, and Andreas Schwab. Fixes: 30eb191c895b ("selftests: riscv: verify ptrace rejects invalid vector csr inputs") Fixes: 2af7c9cf021c ("riscv/ptrace: expose riscv CFI status and state via ptrace and in core files") Cc: Andreas Schwab <schwab@suse.de> Cc: Michael Neuling <mikey@neuling.org> Cc: Charlie Jenkins <thecharlesjenkins@gmail.com> Link: https://patch.msgid.link/20260330024248.449292-1-mikey@neuling.org Link: https://lore.kernel.org/linux-riscv/20260309-fix_selftests-v2-1-9d5a553a531e@gmail.com/ Link: https://lore.kernel.org/linux-riscv/20260309-fix_selftests-v2-3-9d5a553a531e@gmail.com/ Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not setZishun Yi
In set_tagged_addr_ctrl(), when PR_TAGGED_ADDR_ENABLE is not set, pmlen is correctly set to 0, but it forgets to reset pmm. This results in the CPU pmm state not corresponding to the software pmlen state. Fix this by resetting pmm along with pmlen. Fixes: 2e1743085887 ("riscv: Add support for the tagged address ABI") Signed-off-by: Zishun Yi <vulab@iscas.ac.cn> Reviewed-by: Samuel Holland <samuel.holland@sifive.com> Link: https://patch.msgid.link/20260322160022.21908-1-vulab@iscas.ac.cn Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04riscv: make runtime const not usable by modulesJisheng Zhang
Similar as commit 284922f4c563 ("x86: uaccess: don't use runtime-const rewriting in modules") does, make riscv's runtime const not usable by modules too, to "make sure this doesn't get forgotten the next time somebody wants to do runtime constant optimizations". The reason is well explained in the above commit: "The runtime-const infrastructure was never designed to handle the modular case, because the constant fixup is only done at boot time for core kernel code." Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Link: https://patch.msgid.link/20260221023731.3476-1-jszhang@kernel.org Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04riscv: patch: Avoid early phys_to_page()Vivian Wang
Similarly to commit 8d09e2d569f6 ("arm64: patching: avoid early page_to_phys()"), avoid using phys_to_page() for the kernel address case in patch_map(). Since this is called from apply_boot_alternatives() in setup_arch(), and commit 4267739cabb8 ("arch, mm: consolidate initialization of SPARSE memory model") has moved sparse_init() to after setup_arch(), phys_to_page() is not available there yet, and it panics on boot with SPARSEMEM on RV32, which does not use SPARSEMEM_VMEMMAP. Reported-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Closes: https://lore.kernel.org/r/20260223144108-dcace0b9-02e8-4b67-a7ce-f263bed36f26@linutronix.de/ Fixes: 4267739cabb8 ("arch, mm: consolidate initialization of SPARSE memory model") Suggested-by: Mike Rapoport <rppt@kernel.org> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Tested-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20260310-riscv-sparsemem-alternatives-fix-v1-1-659d5dd257e2@iscas.ac.cn [pjw@kernel.org: fix the subject line to align with the patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04riscv: kgdb: fix several debug register assignment bugsPaul Walmsley
Fix several bugs in the RISC-V kgdb implementation: - The element of dbg_reg_def[] that is supposed to pertain to the S1 register embeds instead the struct pt_regs offset of the A1 register. Fix this to use the S1 register offset in struct pt_regs. - The sleeping_thread_to_gdb_regs() function copies the value of the S10 register into the gdb_regs[] array element meant for the S9 register, and copies the value of the S11 register into the array element meant for the S10 register. It also neglects to copy the value of the S11 register. Fix all of these issues. Fixes: fe89bd2be8667 ("riscv: Add KGDB support") Cc: Vincent Chen <vincent.chen@sifive.com> Link: https://patch.msgid.link/fde376f8-bcfd-bfe4-e467-07d8f7608d05@kernel.org Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-04Drivers: hv: Move add_interrupt_randomness() to hypervisor callback sysvecMichael Kelley
The Hyper-V ISRs, for normal guests and when running in the hypervisor root patition, are calling add_interrupt_randomness() as a primary source of entropy. The call is currently in the ISRs as a common place to handle both x86/x64 and arm64. On x86/x64, hypervisor interrupts come through a custom sysvec entry, and do not go through a generic interrupt handler. On arm64, hypervisor interrupts come through an emulated GICv3. GICv3 uses the generic handler handle_percpu_devid_irq(), which does not do add_interrupt_randomness() -- unlike its counterpart handle_percpu_irq(). But handle_percpu_devid_irq() is now updated to do the add_interrupt_randomness(). So add_interrupt_randomness() is now needed only in Hyper-V's x86/x64 custom sysvec path. Move add_interrupt_randomness() from the Hyper-V ISRs into the Hyper-V x86/x64 custom sysvec path, matching the existing STIMER0 sysvec path. With this change, add_interrupt_randomness() is no longer called from any device drivers, which is appropriate. Signed-off-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Acked-by: Wei Liu <wei.liu@kernel.org> Link: https://patch.msgid.link/20260402202400.1707-3-mhklkml@zohomail.com
2026-04-04Merge tag 'v7.0-rc6' into irq/coreThomas Gleixner
to be able to merge the hyper-v patch related to randomness.
2026-04-04Merge tag 'amd-pstate-v7.1-2026-04-02' of ↵Rafael J. Wysocki
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux Pull amd-pstate new content for 7.1 (2026-04-02) from Mario Limonciello: "Add support for new features: * CPPC performance priority * Dynamic EPP * Raw EPP * New unit tests for new features Fixes for: * PREEMPT_RT * sysfs files being present when HW missing * Broken/outdated documentation" * tag 'amd-pstate-v7.1-2026-04-02' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux: (22 commits) MAINTAINERS: amd-pstate: Step down as maintainer, add Prateek as reviewer cpufreq: Pass the policy to cpufreq_driver->adjust_perf() cpufreq/amd-pstate: Pass the policy to amd_pstate_update() cpufreq/amd-pstate-ut: Add a unit test for raw EPP cpufreq/amd-pstate: Add support for raw EPP writes cpufreq/amd-pstate: Add support for platform profile class cpufreq/amd-pstate: add kernel command line to override dynamic epp cpufreq/amd-pstate: Add dynamic energy performance preference Documentation: amd-pstate: fix dead links in the reference section cpufreq/amd-pstate: Cache the max frequency in cpudata Documentation/amd-pstate: Add documentation for amd_pstate_floor_{freq,count} Documentation/amd-pstate: List amd_pstate_prefcore_ranking sysfs file Documentation/amd-pstate: List amd_pstate_hw_prefcore sysfs file amd-pstate-ut: Add a testcase to validate the visibility of driver attributes amd-pstate-ut: Add module parameter to select testcases amd-pstate: Introduce a tracepoint trace_amd_pstate_cppc_req2() amd-pstate: Add sysfs support for floor_freq and floor_count amd-pstate: Add support for CPPC_REQ2 and FLOOR_PERF x86/cpufeatures: Add AMD CPPC Performance Priority feature. amd-pstate: Make certain freq_attrs conditionally visible ...
2026-04-04Merge tag 'microchip-soc-7.1' of ↵Krzysztof Kozlowski
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/at91/linux into soc/arm Microchip ARM64 SoC updates for v7.1 This update includes: - use a top-level configuration flag for all Microchip platforms * tag 'microchip-soc-7.1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/at91/linux: arm64: Kconfig: provide a top-level switch for Microchip platforms Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-04-04Merge tag 'microchip-dt64-7.1' of ↵Krzysztof Kozlowski
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/at91/linux into soc/dt Microchip ARM64 device tree updates for v7.1 This update includes: - device tree files for the Microchip LAN9691 SoC and its evaluation board (Microchip EV23X71A) * tag 'microchip-dt64-7.1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/at91/linux: arm64: dts: microchip: add EV23X71A board dt-bindings: arm: AT91: document EV23X71A board arm64: dts: microchip: add LAN969x support arm64: dts: microchip: add LAN969x clock header file Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-04-04Merge tag 'at91-dt-7.1' of ↵Krzysztof Kozlowski
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/at91/linux into soc/dt Microchip AT91 device tree updates for v7.1 This update includes: - enable LVDS, LCD and PMU for SAMA7D64 SoC - drop unused #address-cells, #size-cells for SAM9X60 UDC node * tag 'at91-dt-7.1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/at91/linux: ARM: dts: microchip: sama7d65: add Cortex-A7 PMU node arm: dts: microchip: remove unused #address-cells/#size-cells from sam9x60 udc node ARM: dts: microchip: sama7d65: add LVDS controller ARM: dts: microchip: sama7d65: add LCD controller Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-04-04Merge tag 'at91-defconfig-7.1' of ↵Krzysztof Kozlowski
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/at91/linux into soc/defconfig Microchip AT91 defconfig updates for v7.1 This update includes: - LCD controller, LVDS controller, backlight, simple pannel, touchscreen configuration flags required by SAMA7D65 SoC * tag 'at91-defconfig-7.1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/at91/linux: ARM: configs: at91: sama7: enable LVDS serializer support ARM: configs: at91: sama7: enable config for atmel maxtouch ARM: configs: at91: sama7: enable DRM hlcdc support Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-04-04Merge tag 'at91-fixes-7.0' of ↵Krzysztof Kozlowski
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/at91/linux into arm/fixes Microchip AT91 fixes for v7.0 This update includes: - fix gpio-lines for SAM9X7 PIOB GPIO controller * tag 'at91-fixes-7.0' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/at91/linux: ARM: dts: microchip: sam9x7: fix gpio-lines count for pioB Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-04-04Merge tag 'imx-dt64-7.1' of ↵Krzysztof Kozlowski
https://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux into soc/dt Krzysztof notes: 1. This might impact users of i.MX8MM SPDIF as compatible is being replaced. Frank Li writes: i.MX arm64 device tree changes for 7.1: - New Board Support S32N79-RDB, Variscite DART-MX95, DART-MX91 with Sonata carrier boards, Verdin iMX95 with multiple carrier boards (Yavia, Mallow, Ivy, Dahlia) TQMa93xx/MBa93xxLA-MINI, SolidRun i.MX8MP HummingBoard IIoT, SolidRun i.MX8MM SOM and EVB, SolidRun SolidSense-N8 board Ka-Ro Electronics tx8m-1610 COM, GOcontroll Moduline IV and Moduline Mini, NXP FRDM-IMX91S board, i.MX93 Wireless EVK board with Wireless SiP, NXP i.MX8MP audio board v2. - USB & Type-C Support Type-C and USB nodes for imx943, correct power-fole for imx8qxp-mek/imx8qm-mek. - Audio Enhancements PDM microphone, bt-sco, and WM8962 sound card support for i.MX952. AONMIX MQS for i.MX95. Use audio-graph-card2 for imx8dxl-evk. WM8904 audio codec for imx8mm-var-som. - Thermal & Cooling PF09/53 thermal zone, fan node, active cooling on A55, SCMI sensor/lmm/cpu for imx943/imx94. - Display Support Multiple LVDS and parallel display overlays for TQ boards (imx91/imx93). Parallel display for i.MX93. ontat,kd50g21-40nt-a1 panel for imx93-9x9-qsb. pixpaper display overlay for i.MX93 FRDM. - Networking Multiple queue configuration on eqos for TQMa8MPxL. MaxLinear PHY support, MCP251xFD CAN controller for imx8mm-var-som. SDIO WiFi support (imx91-evk, imx8mp-evk, imx943-evk) - Bluetooth Support imx943-evk, imx93-14x14-evk, imx95-19x19-evk, imx8mp-evk, imx8mn-evk, imx8mm-evk. - Miscellaneous xspi and MT35XU01G SPI NOR flash for i.MX952. V2X/ELE mailbox nodes, SCMI misc ctrl-ids for imx94. eDMA channel reservation for V2X, Cortex M7 support for imx95. Ethos-U65 NPU and SRAM nodes for imx93. Wire up DMA IRQ for PCIe for imx8qm-ss-hsio. - Bug Fixes & Improvements Complete pinmux for rcwsr12 to fix I2C bus recovery affect other module pinmux for layscape platform. Multiple bug fixes for GPIO polarity, IRQ types, pinmux configurations. GICv3 PPI interrupt CPU mask cleanup across multiple SoCs. Fixed Ethernet PHY IRQ types on TQ boards. Fixed UART RTS/CTS muxing issues. Fixed SD card issues on Kontron boards. Fixed touch reset configuration. Removed fallback ethernet-phy-ieee802.3-c22 where appropriate. Move funnel outside from soc. TMU sensor ID cleanup. Change usdhc tuning step for eMMC and SD. Hexadecimal format, readability improvements, duplicate removal. * tag 'imx-dt64-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux: (139 commits) arm64: dts: imx8qxp-mek: switch Type-C connector power-role to dual arm64: dts: imx8qm-mek: switch Type-C connector power-role to dual arm64: dts: lx2162a-clearfog: set sfp connector leds function and source arm64: dts: lx2162a-sr-som: add crypto & rtc aliases, model arm64: dts: lx2160a-cex7: add rtc alias arm64: dts: lx2160a: complete pinmux for rcwsr12 configuration word arm64: dts: lx2160a: change zeros to hexadecimal in pinmux nodes arm64: dts: lx2160a: add sda gpio references for i2c bus recovery arm64: dts: lx2160a: rename pinmux nodes for readability arm64: dts: lx2160a: remove duplicate pinmux nodes arm64: dts: lx2160a: change i2c0 (iic1) pinmux mask to one bit arm64: dts: lx2160a-cex7/lx2162a-sr-som: fix usd-cd & gpio pinmux arm64: dts: freescale: imx8mp-moduline-display-106: add typec-power-opmode property arm64: dts: imx8mp-tqma8mpql: Add DT overlays to explicit list arm64: dts: imx8mp-evk: Specify ADV7535 register addresses arm64: dts: imx8dxl-evk: Use audio-graph-card2 for wm8960-2 and wm8960-3 arm64: dts: imx943-evk: Add pf09/53 thermal zone arm64: dts: imx943-evk: Add fan node and enable active cooling on A55 arm64: dts: imx943-evk: Add nxp,ctrl-ids for scmi_misc arm64: dts: imx943: Add thermal support ... Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-04-04Merge tag 'tegra-for-7.1-arm64-dt' of ↵Krzysztof Kozlowski
https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/dt arm64: tegra: Device tree changes for v7.1-rc1 Various fixes and new additions across a number of devices. GPIO and PCI are enabled on Tegra264 and the Jetson AGX Thor Developer Kit, allowing it to boot via network and mass storage. * tag 'tegra-for-7.1-arm64-dt' of https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: arm64: tegra: Add Tegra264 GPIO controllers arm64: tegra: smaug: Enable SPI-NOR flash arm64: tegra: Add Jetson AGX Thor Developer Kit support arm64: tegra: Add PCI controllers on Tegra264 arm64: tegra: Fix RTC aliases arm64: tegra: Drop redundant clock and reset names for TSEC arm64: tegra: Fix snps,blen properties dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-04-04Merge tag 'tegra-for-7.1-arm-dt' of ↵Krzysztof Kozlowski
https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/dt ARM: tegra: Device tree changes for v7.1-rc1 Various improvements for Tegra114 boards, as well as some legacy cleanup for PAZ00 and Transformers devices. * tag 'tegra-for-7.1-arm-dt' of https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: ARM: tegra: paz00: Configure WiFi rfkill switch through device tree ARM: tegra: transformers: Add connector node ARM: tegra: Add External Memory Controller node on Tegra114 ARM: tegra: Add ACTMON node to Tegra114 device tree ARM: tegra: lg-x3: Add node for capacitive buttons ARM: tegra: lg-x3: Add USB and power related nodes ARM: tegra: lg-x3: Add panel and bridge nodes ARM: tn7: Adjust panel node ARM: tegra: Add SOCTHERM support on Tegra114 Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-04-04x86/fpu: Correct misspelled xfeaures_to_write local varBorislav Petkov (AMD)
It happens. Fix it. No functional changes. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260404120048.14765-1-bp@kernel.org
2026-04-04RISC-V: KVM: Reuse KVM_CAP_VM_GPA_BITS to select HGATP.MODEFangyu Yu
Reuse KVM_CAP_VM_GPA_BITS to advertise and select the effective G-stage GPA width for a VM. KVM_CHECK_EXTENSION(KVM_CAP_VM_GPA_BITS) returns the effective GPA bits for a VM, KVM_ENABLE_CAP(KVM_CAP_VM_GPA_BITS) allows userspace to downsize the effective GPA width by selecting a smaller G-stage page table format: - gpa_bits <= 41 selects Sv39x4 (pgd_levels=3) - gpa_bits <= 50 selects Sv48x4 (pgd_levels=4) - gpa_bits <= 59 selects Sv57x4 (pgd_levels=5) Reject the request with -EINVAL for unsupported values and with -EBUSY if vCPUs have been created or any memslot is populated. Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Reviewed-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Reviewed-by: Guo Ren <guoren@kernel.org> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260403153019.9916-4-fangyu.yu@linux.alibaba.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-04-04RISC-V: KVM: Cache gstage pgd_levels in struct kvm_gstageFangyu Yu
Gstage page-table helpers frequently chase gstage->kvm->arch to fetch pgd_levels. This adds noise and repeats the same dereference chain in hot paths. Add pgd_levels to struct kvm_gstage and initialize it from kvm->arch when setting up a gstage instance. Introduce kvm_riscv_gstage_init() to centralize initialization and switch gstage code to use gstage->pgd_levels. Suggested-by: Anup Patel <anup@brainfault.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Reviewed-by: Anup Patel <anup@brainfault.org> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com> Link: https://lore.kernel.org/r/20260403153019.9916-3-fangyu.yu@linux.alibaba.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-04-04RISC-V: KVM: Support runtime configuration for per-VM's HGATP modeFangyu Yu
Introduces one per-VM architecture-specific fields to support runtime configuration of the G-stage page table format: - kvm->arch.pgd_levels: the corresponding number of page table levels for the selected mode. These fields replace the previous global variables kvm_riscv_gstage_mode and kvm_riscv_gstage_pgd_levels, enabling different virtual machines to independently select their G-stage page table format instead of being forced to share the maximum mode detected by the kernel at boot time. Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Reviewed-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Reviewed-by: Anup Patel <anup@brainfault.org> Reviewed-by: Guo Ren <guoren@kernel.org> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com> Link: https://lore.kernel.org/r/20260403153019.9916-2-fangyu.yu@linux.alibaba.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-04-03Merge tag 'powerpc-7.0-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fix from Madhavan Srinivasan: - fix iommu incorrectly bypassing DMA APIs Thanks to Dan Horak, Gaurav Batra, and Ritesh Harjani (IBM). * tag 'powerpc-7.0-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/powernv/iommu: iommu incorrectly bypass DMA APIs
2026-04-03Merge tag 's390-7.0-7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Vasily Gorbik: - Fix a memory leak in the zcrypt driver where the AP message buffer for clear key RSA requests was allocated twice, once by the caller and again locally, causing the first allocation to never be freed - Fix the cpum_sf perf sampling rate overflow adjustment to clamp the recalculated rate to the hardware maximum, preventing exceptions on heavily loaded systems running with HZ=1000 * tag 's390-7.0-7' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/zcrypt: Fix memory leak with CCA cards used as accelerator s390/cpum_sf: Cap sampling rate to prevent lsctl exception
2026-04-03KVM: nSVM: Fail emulation of VMRUN/VMLOAD/VMSAVE if mapping vmcb12 failsYosry Ahmed
KVM currently injects a #GP if mapping vmcb12 fails when emulating VMRUN/VMLOAD/VMSAVE. This is not architectural behavior, as #GP should only be injected if the physical address is not supported or not aligned. Instead, handle it as an emulation failure, similar to how nVMX handles failures to read/write guest memory in several emulation paths. When virtual VMLOAD/VMSAVE is enabled, if vmcb12's GPA is not mapped in the NPTs a VMEXIT(#NPF) will be generated, and KVM will install an MMIO SPTE and emulate the instruction if there is no corresponding memslot. x86_emulate_insn() will return EMULATION_FAILED as VMLOAD/VMSAVE are not handled as part of the twobyte_insn cases. Even though this will also result in an emulation failure, it will only result in a straight return to userspace if KVM_CAP_EXIT_ON_EMULATION_FAILURE is set. Otherwise, it would inject #UD and only exit to userspace if not in guest mode. So the behavior is slightly different if virtual VMLOAD/VMSAVE is enabled. Fixes: 3d6368ef580a ("KVM: SVM: Add VMRUN handler") Reported-by: Jim Mattson <jmattson@google.com> Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260316202732.3164936-8-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-03KVM: SVM: Treat mapping failures equally in VMLOAD/VMSAVE emulationYosry Ahmed
Currently, a #GP is only injected if kvm_vcpu_map() fails with -EINVAL. But it could also fail with -EFAULT if creating a host mapping failed. Inject a #GP in all cases, no reason to treat failure modes differently. Similar to commit 01ddcdc55e09 ("KVM: nSVM: Always inject a #GP if mapping VMCB12 fails on nested VMRUN"), treat all failures equally. Fixes: 8c5fbf1a7231 ("KVM/nSVM: Use the new mapping API for mapping guest memory") Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260316202732.3164936-7-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-03KVM: SVM: Check EFER.SVME and CPL on #GP intercept of SVM instructionsYosry Ahmed
When KVM intercepts #GP on an SVM instruction from L2, it checks the legality of RAX, and injects a #GP if RAX is illegal, or otherwise synthesizes a #VMEXIT to L1. However, checking EFER.SVME and CPL takes precedence over both the RAX check and the intercept. Call nested_svm_check_permissions() first to cover both. Note that if #GP is intercepted on SVM instruction in L1, the intercept handlers of VMRUN/VMLOAD/VMSAVE already perform these checks. Note #2, if KVM does not intercept #GP, the check for EFER.SVME is not done in the correct order, because KVM handles it by intercepting the instructions when EFER.SVME=0 and injecting #UD. However, a #GP injected by hardware would happen before the instruction intercept, leading to #GP taking precedence over #UD from the guest's perspective. Opportunistically add a FIXME for this. Fixes: 82a11e9c6fa2 ("KVM: SVM: Add emulation support for #GP triggered by SVM instructions") Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260316202732.3164936-6-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-03KVM: SVM: Move RAX legality check to SVM insn interception handlersYosry Ahmed
When #GP is intercepted by KVM, the #GP interception handler checks whether the GPA in RAX is legal and reinjects the #GP accordingly. Otherwise, it calls into the appropriate interception handler for VMRUN/VMLOAD/VMSAVE. The intercept handlers do not check RAX. However, the intercept handlers need to do the RAX check, because if the guest has a smaller MAXPHYADDR, RAX could be legal from the hardware perspective (i.e. CPU does not inject #GP), but not from the vCPU's perspective. Note that with allow_smaller_maxphyaddr, both NPT and VLS cannot be used, so VMLOAD/VMSAVE have to be intercepted, and RAX can always be checked against the vCPU's MAXPHYADDR. Move the check into the interception handlers for VMRUN/VMLOAD/VMSAVE as the CPU does not check RAX before the interception. Read RAX using kvm_register_read() to avoid a false negative on page_address_valid() on 32-bit due to garbage in the higher bits. Keep the check in the #GP intercept handler in the nested case where a #VMEXIT is synthesized into L1, as the RAX check is still needed there and takes precedence over the intercept. Opportunistically add a FIXME about the #VMEXIT being synthesized into L1, as it needs to be conditional. Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260316202732.3164936-5-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-03KVM: SVM: Properly check RAX on #GP intercept of SVM instructionsYosry Ahmed
When KVM intercepts #GP on an SVM instruction, it re-injects the #GP if the instruction was executed with a mis-algined RAX. However, a #GP should also be reinjected if RAX contains an illegal GPA, according to the APM, one of #GP conditions is: rAX referenced a physical address above the maximum supported physical address. Replace the PAGE_MASK check with page_address_valid(), which checks both page-alignment as well as the legality of the GPA based on the vCPU's MAXPHYADDR. Use kvm_register_read() to read RAX to so that bits 63:32 are dropped when the vCPU is in 32-bit mode, i.e. to avoid a false positive when checking the validity of the address. Note that this is currently only a problem if KVM is running an L2 guest and ends up synthesizing a #VMEXIT to L1, as the RAX check takes precedence over the intercept. Otherwise, if KVM emulates the instruction, kvm_vcpu_map() should fail on illegal GPAs and inject a #GP anyway. However, following patches will change the failure behavior of kvm_vcpu_map(), so make sure the #GP interception handler does this appropriately. Opportunistically drop a teaser FIXME about the SVM instructions handling on #GP belonging in the emulator. Fixes: 82a11e9c6fa2 ("KVM: SVM: Add emulation support for #GP triggered by SVM instructions") Fixes: d1cba6c92237 ("KVM: x86: nSVM: test eax for 4K alignment for GP errata workaround") Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260316202732.3164936-4-yosry@kernel.org [sean: massage wording with respect to kvm_register_read()] Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-03KVM: SVM: Refactor SVM instruction handling on #GP interceptYosry Ahmed
Instead of returning an opcode from svm_instr_opcode() and then passing it to emulate_svm_instr(), which uses it to find the corresponding exit code and intercept handler, return the exit code directly from svm_instr_opcode(), and rename it to svm_get_decoded_instr_exit_code(). emulate_svm_instr() boils down to synthesizing a #VMEXIT or calling the intercept handler, so open-code it in gp_interception(), and use svm_invoke_exit_handler() to call the intercept handler based on the exit code. This allows for dropping the SVM_INSTR_* enum, and the const array mapping its values to exit codes and intercept handlers. In gp_intercept(), handle SVM instructions and first with an early return, and invert is_guest_mode() checks, un-indenting the rest of the code. No functional change intended. Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260316202732.3164936-3-yosry@kernel.org [sean: add BUILD_BUG_ON(), tweak formatting/naming] Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-03KVM: SVM: Properly check RAX in the emulator for SVM instructionsYosry Ahmed
Architecturally, VMRUN/VMLOAD/VMSAVE should generate a #GP if the physical address in RAX is not supported. check_svme_pa() hardcodes this to checking that bits 63-48 are not set. This is incorrect on HW supporting 52 bits of physical address space. Additionally, the emulator does not check if the address is not aligned, which should also result in #GP. Use page_address_valid() which properly checks alignment and the address legality based on the guest's MAXPHYADDR. Plumb it through x86_emulate_ops, similar to is_canonical_addr(), to avoid directly accessing the vCPU object in emulator code. Fixes: 01de8b09e606 ("KVM: SVM: Add intercept checks for SVM instructions") Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260316202732.3164936-2-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-04x86/apic: Drop AMD Extended Interrupt LVT macrosNaveen N Rao (AMD)
AMD defines Extended Interrupt Local Vector Table (EILVT) registers to allow for additional interrupt sources. While the APIC registers for those are unique to AMD, the format of those registers follows the standard LVT registers. Drop EILVT-specific macros in favor of the standard APIC LVT macros. Drop unused APIC_EILVT_NR_AMD_K8 and APIC_EILVT_LVTOFF while at it. No functional change. [ bp: Merge the two cleanup patches into one. ] Signed-off-by: Naveen N Rao (AMD) <naveen@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Tested-by: Manali Shukla <manali.shukla@amd.com> Link: https://patch.msgid.link/b98d69037c0102d2ccd082a941888a689cd214c9.1775019269.git.naveen@kernel.org
2026-04-03KVM: SEV: Disallow LAUNCH_FINISH if vCPUs are actively being createdSean Christopherson
Reject LAUNCH_FINISH for SEV-ES and SNP VMs if KVM is actively creating one or more vCPUs, as KVM needs to process and encrypt each vCPU's VMSA. Letting userspace create vCPUs while LAUNCH_FINISH is in-progress is "fine", at least in the current code base, as kvm_for_each_vcpu() operates on online_vcpus, LAUNCH_FINISH (all SEV+ sub-ioctls) holds kvm->mutex, and fully onlining a vCPU in kvm_vm_ioctl_create_vcpu() is done under kvm->mutex. I.e. there's no difference between an in-progress vCPU and a vCPU that is created entirely after LAUNCH_FINISH. However, given that concurrent LAUNCH_FINISH and vCPU creation can't possibly work (for any reasonable definition of "work"), since userspace can't guarantee whether a particular vCPU will be encrypted or not, disallow the combination as a hardening measure, to reduce the probability of introducing bugs in the future, and to avoid having to reason about the safety of future changes related to LAUNCH_FINISH. Cc: Jethro Beekman <jethro@fortanix.com> Closes: https://lore.kernel.org/all/b31f7c6e-2807-4662-bcdd-eea2c1e132fa@fortanix.com Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260310234829.2608037-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-03KVM: SEV: Protect *all* of sev_mem_enc_register_region() with kvm->lockSean Christopherson
Take and hold kvm->lock for before checking sev_guest() in sev_mem_enc_register_region(), as sev_guest() isn't stable unless kvm->lock is held (or KVM can guarantee KVM_SEV_INIT{2} has completed and can't rollack state). If KVM_SEV_INIT{2} fails, KVM can end up trying to add to a not-yet-initialized sev->regions_list, e.g. triggering a #GP Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 110 UID: 0 PID: 72717 Comm: syz.15.11462 Tainted: G U W O 6.16.0-smp-DEV #1 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024 RIP: 0010:sev_mem_enc_register_region+0x3f0/0x4f0 ../include/linux/list.h:83 Code: <41> 80 3c 04 00 74 08 4c 89 ff e8 f1 c7 a2 00 49 39 ed 0f 84 c6 00 RSP: 0018:ffff88838647fbb8 EFLAGS: 00010256 RAX: dffffc0000000000 RBX: 1ffff92015cf1e0b RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000001000 RDI: ffff888367870000 RBP: ffffc900ae78f050 R08: ffffea000d9e0007 R09: 1ffffd4001b3c000 R10: dffffc0000000000 R11: fffff94001b3c001 R12: 0000000000000000 R13: ffff8982ab0bde00 R14: ffffc900ae78f058 R15: 0000000000000000 FS: 00007f34e9dc66c0(0000) GS:ffff89ee64d33000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe180adef98 CR3: 000000047210e000 CR4: 0000000000350ef0 Call Trace: <TASK> kvm_arch_vm_ioctl+0xa72/0x1240 ../arch/x86/kvm/x86.c:7371 kvm_vm_ioctl+0x649/0x990 ../virt/kvm/kvm_main.c:5363 __se_sys_ioctl+0x101/0x170 ../fs/ioctl.c:51 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x6f/0x1f0 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f34e9f7e9a9 Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f34e9dc6038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f34ea1a6080 RCX: 00007f34e9f7e9a9 RDX: 0000200000000280 RSI: 000000008010aebb RDI: 0000000000000007 RBP: 00007f34ea000d69 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f34ea1a6080 R15: 00007ffce77197a8 </TASK> with a syzlang reproducer that looks like: syz_kvm_add_vcpu$x86(0x0, &(0x7f0000000040)={0x0, &(0x7f0000000180)=ANY=[], 0x70}) (async) syz_kvm_add_vcpu$x86(0x0, &(0x7f0000000080)={0x0, &(0x7f0000000180)=ANY=[@ANYBLOB="..."], 0x4f}) (async) r0 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000200), 0x0, 0x0) r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0) r2 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000240), 0x0, 0x0) r3 = ioctl$KVM_CREATE_VM(r2, 0xae01, 0x0) ioctl$KVM_SET_CLOCK(r3, 0xc008aeba, &(0x7f0000000040)={0x1, 0x8, 0x0, 0x5625e9b0}) (async) ioctl$KVM_SET_PIT2(r3, 0x8010aebb, &(0x7f0000000280)={[...], 0x5}) (async) ioctl$KVM_SET_PIT2(r1, 0x4070aea0, 0x0) (async) r4 = ioctl$KVM_CREATE_VM(0xffffffffffffffff, 0xae01, 0x0) openat$kvm(0xffffffffffffff9c, 0x0, 0x0, 0x0) (async) ioctl$KVM_SET_USER_MEMORY_REGION(r4, 0x4020ae46, &(0x7f0000000400)={0x0, 0x0, 0x0, 0x2000, &(0x7f0000001000/0x2000)=nil}) (async) r5 = ioctl$KVM_CREATE_VCPU(r4, 0xae41, 0x2) close(r0) (async) openat$kvm(0xffffffffffffff9c, &(0x7f0000000000), 0x8000, 0x0) (async) ioctl$KVM_SET_GUEST_DEBUG(r5, 0x4048ae9b, &(0x7f0000000300)={0x4376ea830d46549b, 0x0, [0x46, 0x0, 0x0, 0x0, 0x0, 0x1000]}) (async) ioctl$KVM_RUN(r5, 0xae80, 0x0) Opportunistically use guard() to avoid having to define a new error label and goto usage. Fixes: 1e80fdc09d12 ("KVM: SVM: Pin guest memory when SEV is active") Cc: stable@vger.kernel.org Reported-by: Alexander Potapenko <glider@google.com> Tested-by: Alexander Potapenko <glider@google.com> Link: https://patch.msgid.link/20260310234829.2608037-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-03KVM: SEV: Reject attempts to sync VMSA of an already-launched/encrypted vCPUSean Christopherson
Reject synchronizing vCPU state to its associated VMSA if the vCPU has already been launched, i.e. if the VMSA has already been encrypted. On a host with SNP enabled, accessing guest-private memory generates an RMP #PF and panics the host. BUG: unable to handle page fault for address: ff1276cbfdf36000 #PF: supervisor write access in kernel mode #PF: error_code(0x80000003) - RMP violation PGD 5a31801067 P4D 5a31802067 PUD 40ccfb5063 PMD 40e5954063 PTE 80000040fdf36163 SEV-SNP: PFN 0x40fdf36, RMP entry: [0x6010fffffffff001 - 0x000000000000001f] Oops: Oops: 0003 [#1] SMP NOPTI CPU: 33 UID: 0 PID: 996180 Comm: qemu-system-x86 Tainted: G OE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. PowerEdge R7625/0H1TJT, BIOS 1.5.8 07/21/2023 RIP: 0010:sev_es_sync_vmsa+0x54/0x4c0 [kvm_amd] Call Trace: <TASK> snp_launch_update_vmsa+0x19d/0x290 [kvm_amd] snp_launch_finish+0xb6/0x380 [kvm_amd] sev_mem_enc_ioctl+0x14e/0x720 [kvm_amd] kvm_arch_vm_ioctl+0x837/0xcf0 [kvm] kvm_vm_ioctl+0x3fd/0xcc0 [kvm] __x64_sys_ioctl+0xa3/0x100 x64_sys_call+0xfe0/0x2350 do_syscall_64+0x81/0x10f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7ffff673287d </TASK> Note, the KVM flaw has been present since commit ad73109ae7ec ("KVM: SVM: Provide support to launch and run an SEV-ES guest"), but has only been actively dangerous for the host since SNP support was added. With SEV-ES, KVM would "just" clobber guest state, which is totally fine from a host kernel perspective since userspace can clobber guest state any time before sev_launch_update_vmsa(). Fixes: ad27ce155566 ("KVM: SEV: Add KVM_SEV_SNP_LAUNCH_FINISH command") Reported-by: Jethro Beekman <jethro@fortanix.com> Closes: https://lore.kernel.org/all/d98692e2-d96b-4c36-8089-4bc1e5cc3d57@fortanix.com Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260310234829.2608037-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>