summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2026-05-16riscv: dts: spacemit: k1-musepi-pro: add 24c02 eepromAndre Heider
Enable i2c2 and add the connected GT24C02B EEPROM. It contains an ONIE TLV table: => tlv_eeprom TLV: 0 [ 12.162] TlvInfo Header: [ 12.162] Id String: TlvInfo [ 12.165] Version: 1 [ 12.168] Total Length: 58 [ 12.171] TLV Name Code Len Value [ 12.175] -------------------- ---- --- ----- [ 12.179] Product Name 0x21 16 k1-x_MUSE-Pi-Pro [ 12.184] Serial Number 0x23 17 BPMIMXXXXXXXXXXXX [ 12.189] Unknown 0x41 1 0x02 [ 12.194] Base MAC Address 0x24 6 FE:FE:FE:XX:XX:XX [ 12.199] MAC Addresses 0x2A 2 2 [ 12.203] CRC-32 0xFE 4 0x395ECD34 [ 12.207] Checksum is valid. (With 0x41 as TLV_CODE_DDR_CSNUM) Signed-off-by: Andre Heider <a.heider@gmail.com> Link: https://patch.msgid.link/20260513071958.29574-3-a.heider@gmail.com Signed-off-by: Yixun Lan <dlan@kernel.org>
2026-05-16riscv: dts: spacemit: k1-musepi-pro: add PMIC and power infrastructureAndre Heider
Enable i2c8 and add the connected SpacemiT P1 PMIC with its related regulators for the board's power infrastructure and voltage regulation support. Signed-off-by: Andre Heider <a.heider@gmail.com> Link: https://patch.msgid.link/20260513071958.29574-2-a.heider@gmail.com Signed-off-by: Yixun Lan <dlan@kernel.org>
2026-05-16riscv: dts: spacemit: k1-bananapi-f3: add SD card support with UHS modesIker Pedrosa
Add complete SD card controller support with UHS high-speed modes. - Enable sdhci0 controller with 4-bit bus width - Configure card detect GPIO with GPIO_ACTIVE_LOW and internal pull-up support - Connect vmmc-supply to buck4 for 3.3V card power - Connect vqmmc-supply to aldo1 for 1.8V/3.3V I/O switching - Add dual pinctrl states for voltage-dependent pin configuration - Support UHS-I SDR25, SDR50, and SDR104 modes - Add stable MMC device aliases (mmc0 = eMMC, mmc1 = SD card) This enables full SD card functionality including high-speed UHS modes for improved performance. Suggested-by: Anand Moon <linux.amoon@gmail.com> Tested-by: Anand Moon <linux.amoon@gmail.com> Tested-by: Margherita Milani <margherita.milani@amarulasolutions.com> Tested-by: Aurelien Jarno <aurelien@aurel32.net> Reviewed-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com> Link: https://patch.msgid.link/20260515-orangepi-sd-card-uhs-v10-3-094af27e310d@gmail.com Signed-off-by: Yixun Lan <dlan@kernel.org>
2026-05-16riscv: dts: spacemit: k1-orangepi-rv2: add SD card support with UHS modesIker Pedrosa
Add complete SD card controller support with UHS high-speed modes. - Enable sdhci0 controller with 4-bit bus width - Configure card detect GPIO with GPIO_ACTIVE_LOW logic - Connect vmmc-supply to buck4 for 3.3V card power - Connect vqmmc-supply to aldo1 for 1.8V/3.3V I/O switching - Add dual pinctrl states for voltage-dependent pin configuration - Support UHS-I SDR25, SDR50, and SDR104 modes - Add stable MMC device aliases (mmc0 = eMMC, mmc1 = SD card) This enables full SD card functionality including high-speed UHS modes for improved performance. Tested-by: Anand Moon <linux.amoon@gmail.com> Tested-by: Trevor Gamblin <tgamblin@baylibre.com> Tested-by: Michael Opdenacker <michael.opdenacker@rootcommit.com> Tested-by: Vincent Legoll <legoll@online.fr> Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com> Link: https://patch.msgid.link/20260515-orangepi-sd-card-uhs-v10-2-094af27e310d@gmail.com Signed-off-by: Yixun Lan <dlan@kernel.org>
2026-05-16riscv: dts: spacemit: k1: add SD card controller and pinctrl supportIker Pedrosa
Add SD card controller infrastructure for SpacemiT K1 SoC with complete pinctrl support for both standard and UHS modes. - Add sdhci0 controller definition with clocks, resets and interrupts - Add mmc1_cfg pinctrl for 3.3V standard SD operation - Add mmc1_uhs_cfg pinctrl for 1.8V UHS high-speed operation - Configure appropriate drive strength and power-source properties This provides complete SD card infrastructure that K1-based boards can enable. Tested-by: Anand Moon <linux.amoon@gmail.com> Tested-by: Trevor Gamblin <tgamblin@baylibre.com> Tested-by: Vincent Legoll <legoll@online.fr> Reviewed-by: Troy Mitchell <troy.mitchell@linux.dev> Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com> Link: https://patch.msgid.link/20260515-orangepi-sd-card-uhs-v10-1-094af27e310d@gmail.com Signed-off-by: Yixun Lan <dlan@kernel.org>
2026-05-15Merge tag 'for-linus-7.1b-rc4-tag' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen fixes from Juergen Gross: - one simple cleanup - a fix for a corner case when running as Xen PV dom0 - a fix of a regression for Xen PV guests, introduced in 7.0 * tag 'for-linus-7.1b-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: x86/xen: Tolerate nested XEN_LAZY_MMU entering/leaving x86/xen: Fix xen_e820_swap_entry_with_ram() xen/arm: Replace __ASSEMBLY__ with __ASSEMBLER__ in interface.h
2026-05-15riscv: dts: microchip: remove redudant enabling of syscontrollerConor Dooley
The system controller is never disabled, there's no need to ever enable it. Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2026-05-15Merge tag 'pxa1908-dt-for-7.2' of ↵Arnd Bergmann
https://codeberg.org/pxa1908-mainline/linux into soc/dt PXA1908 DT changes for 7.2 This set consists of a bug fix and three QoL fixes: * Fix touchscreen breakage in low ambient temperatures on coreprimevelte * Free up most of the framebuffer memory on coreprimevelte * Fill in some missing properties for pre-0.2 PSCI and coreprimevelte SDIO * tag 'pxa1908-dt-for-7.2' of https://codeberg.org/pxa1908-mainline/linux: arm64: dts: marvell: samsung-coreprimevelte: Add missing SDIO properties arm64: dts: marvell: pxa1908: Add PSCI function IDs arm64: dts: marvell: samsung,coreprimevelte: Use memory-region for framebuffer arm64: dts: marvell: samsung-coreprimevelte: Increase touchscreen voltage Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-05-15arm64: dts: ti: k3-am62-verdin: Add DSI to HDMI adapter overlayVitor Soares
Add a device-tree overlay for the Toradex DSI to HDMI Adapter, an accessory that connects to the Verdin DSI_1 interface and provides a full-size HDMI Type-A output. The adapter is based on the Lontium LT8912B DSI-to-HDMI bridge. The overlay is also combined with the Verdin AM62 carrier board device trees to provide ready-to-use DTBs for the Dahlia and Development Board carriers, in both WiFi and non-WiFi SoM variants. Link: https://developer.toradex.com/hardware/accessories/add-ons/dsi-hdmi-adapter Signed-off-by: Vitor Soares <vitor.soares@toradex.com> Link: https://patch.msgid.link/20260506143427.348806-2-ivitro@gmail.com Signed-off-by: Nishanth Menon <nm@ti.com>
2026-05-15ARM: dts: renesas: r8a73a4: Describe coresight on R-Mobile APE6Marek Vasut
Describe coresight topology on R-Mobile APE6. Extend the current PTM node with connection funnel, TPIU, ETB and replicator. The coresight on this hardware is clocked from the ZT/ZTR trace clock. Note that only core 0 part of the topology is described, because the other cores are still not present in the DT. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260502185557.93061-5-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-05-15ARM: dts: renesas: r8a73a4: Add ZT/ZTR trace clock on R-Mobile APE6Marek Vasut
Add ZT trace bus and ZTR trace clock on the R-Mobile APE6. These clock supply the coresight tracing modules, PTM, TPIU, ETB and replicator. Without these clock, the coresight tracing can not be operated. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260502185557.93061-4-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-05-15ARM: Do not select HAVE_RUST when KASAN is enabledNathan Chancellor
When KASAN is enabled, such as with allmodconfig, the build fails when building the Rust code with: error: kernel-address sanitizer is not supported for this target error: aborting due to 1 previous error make[4]: *** [rust/Makefile:654: rust/core.o] Error 1 The arm-unknown-linux-gnueabi target does not support KASAN, so avoid saying Rust is supported when it is enabled. Cc: stable@vger.kernel.org Fixes: ccb8ce526807 ("ARM: 9441/1: rust: Enable Rust support for ARMv7") Link: https://github.com/Rust-for-Linux/linux/issues/1234 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Christian Schrefl <chrisi.schrefl@gmail.com> Link: https://patch.msgid.link/20260511-arm-avoid-rust-with-kasan-v1-1-24d55f4a900b@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-05-14Merge tag 'acpi-7.1-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI support fixes from Rafael Wysocki: "These fix several platform drivers that use the ACPI companion of the given platform device without checking its presence, which may lead to a NULL pointer dereference or other kind of malfunction if the driver is forced to match a device without an ACPI companion via driver override, and restore debug log level for some messages in the ACPI CPPC library: - Check ACPI_COMPANION() against NULL during probe in several core ACPI device drivers (Rafael Wysocki) - Restore log level of messages in amd_set_max_freq_ratio() (Mario Limonciello)" * tag 'acpi-7.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: PAD: xen: Check ACPI_COMPANION() against NULL ACPI: driver: Check ACPI_COMPANION() against NULL during probe Revert "ACPI: CPPC: Adjust debug messages in amd_set_max_freq_ratio() to warn"
2026-05-14Merge branch 'acpi-cppc'Rafael J. Wysocki
Merge a revert of an ACPI CPPC commit that increased the log level of some debug messages which turned out to be a bad idea: - Restore log level of messages in amd_set_max_freq_ratio() (Mario Limonciello) * acpi-cppc: Revert "ACPI: CPPC: Adjust debug messages in amd_set_max_freq_ratio() to warn"
2026-05-14arm64: dts: exynosautov920: enable support for ufs controllerSowon Na
Add ufs node for ExynosAutov920 SoC. Also enable ufs_phy and ufs controller nodes. Signed-off-by: Sowon Na <sowon.na@samsung.com> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com> Link: https://patch.msgid.link/20260417121452.827054-5-alim.akhtar@samsung.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-05-14arm64: dts: exynosautov920: Add syscon hsi2 nodeAlim Akhtar
Syscon HSI2 block has system configuration settings for HSI IPs, like ufs, usb etc. Add a syscon_hsi2 node entry so that related HSI controller can make use of the same. Signed-off-by: Sowon Na <sowon.na@samsung.com> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com> Link: https://patch.msgid.link/20260417121452.827054-2-alim.akhtar@samsung.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-05-14x86/xen: Tolerate nested XEN_LAZY_MMU entering/leavingJuergen Gross
With the support of nested lazy mmu sections it can happen that arch_enter_lazy_mmu_mode() is being called twice without a call of arch_leave_lazy_mmu_mode() in between, as the lazy_mmu_*() helpers are not disabling preemption when checking for nested lazy mmu sections. This is a problem when running as a Xen PV guest, as xen_enter_lazy_mmu() and xen_leave_lazy_mmu() don't tolerate this case. Fix that in xen_enter_lazy_mmu() and xen_leave_lazy_mmu() in order not to hurt all other lazy mmu mode users. Fixes: 291b3abed657 ("x86/xen: use lazy_mmu_state when context-switching") Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Signed-off-by: Juergen Gross <jgross@suse.com> Message-ID: <20260508143933.493013-1-jgross@suse.com>
2026-05-14x86/xen: Fix xen_e820_swap_entry_with_ram()Juergen Gross
When swapping a not page-aligned E820 map entry with RAM, the start address of the modified entry is calculated wrong (the offset into the page is subtracted instead of being added to the page address). Fixes: be35d91c8880 ("xen: tolerate ACPI NVS memory overlapping with Xen allocated memory") Reported-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com> Message-ID: <20260505102417.208138-1-jgross@suse.com>
2026-05-14KVM: x86: nSVM: Save/restore gPAT with KVM_{GET,SET}_NESTED_STATEJim Mattson
Add a 'gpat' field to kvm_svm_nested_state_hdr to carry L2's guest PAT value across save and restore. When KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT is disabled and the vCPU is in guest mode with nested NPT enabled, save vmcb02's g_pat into the header on KVM_GET_NESTED_STATE, and restore it on KVM_SET_NESTED_STATE. Host-initiated accesses to IA32_PAT (via KVM_GET/SET_MSRS) always target L1's hPAT, so they cannot be used to save or restore gPAT. The separate header field ensures that KVM_GET/SET_MSRS and KVM_GET/SET_NESTED_STATE are independent and can be ordered arbitrarily during save and restore. Note that struct kvm_svm_nested_state_hdr is included in a union padded to 120 bytes, so there is room to add the gpat field without changing any offsets. Fixes: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") Signed-off-by: Jim Mattson <jmattson@google.com> Link: https://patch.msgid.link/20260407190343.325299-9-jmattson@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-14KVM: x86: nSVM: Save gPAT to vmcb12.g_pat on VMEXITJim Mattson
According to the APM volume 3 pseudo-code for "VMRUN," when nested paging is enabled in the vmcb, the guest PAT register (gPAT) is saved to the vmcb on emulated VMEXIT. When KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT is disabled and the vCPU is in guest mode with nested NPT enabled, save the vmcb02 g_pat field to the vmcb12 g_pat field on emulated VMEXIT. Fixes: 15038e147247 ("KVM: SVM: obey guest PAT") Signed-off-by: Jim Mattson <jmattson@google.com> Link: https://patch.msgid.link/20260407190343.325299-7-jmattson@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-14KVM: x86: nSVM: Redirect IA32_PAT accesses to either hPAT or gPATJim Mattson
When handling PAT accesses from L2, route PAT accesses to either hPAT or gPAT based on whether or not L2 has a separate PAT, i.e. if KVM is actually emulating gPAT, instead of using L1's PAT for everything. Specifically, if KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT is disabled, the vCPU is in guest mode with nested NPT enabled, *and* the access if from the guest (i.e. is not from the host stuffing PAT as part of save/restore), then redirect guest PAT accesses to the gPAT "register" in vmcb02, i.e. emulate gPAT for L2. Always route non-guest accesses to hPAT, i.e. L1's PAT in vcpu->arch.pat, to ensures that KVM_{G,S}ET_MSRS and KVM_{G,S}ET_NESTED_STATE are independent of each other and can be ordered arbitrarily during save and restore. E.g. if KVM didn't exempt host accesses, then whether a write to PAT hit hPAT or gPAT would vary based on whether userspace restores PAT before or after nested state. Note, gPAT is saved and restored separately via KVM_{G,S}ET_NESTED_STATE. WARN if there's a host-initiated access to PAT from within KVM_RUN, i.e. if KVM itself initiated the access, as there are no such accesses today, and it's not clear what the "right" behavior would be. Fixes: 15038e147247 ("KVM: SVM: obey guest PAT") Signed-off-by: Jim Mattson <jmattson@google.com> Co-developed-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-14KVM: x86: nSVM: Set vmcb02.g_pat correctly for nested NPTJim Mattson
When KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT is disabled and nested NPT is enabled in vmcb12, copy the (cached and validated) vmcb12 g_pat field to vmcb02's g_pat, giving L2 its own independent guest PAT register. When the quirk is enabled (default), or when NPT is enabled but nested NPT is disabled, copy L1's IA32_PAT MSR to the vmcb02 g_pat field, since L2 shares the IA32_PAT MSR with L1. When NPT is disabled, the g_pat field is ignored by hardware. Fixes: 15038e147247 ("KVM: SVM: obey guest PAT") Signed-off-by: Jim Mattson <jmattson@google.com> Link: https://patch.msgid.link/20260407190343.325299-5-jmattson@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-14KVM: x86: nSVM: Cache and validate vmcb12 g_patJim Mattson
When KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT is disabled and nested paging is enabled in vmcb12, validate g_pat at emulated VMRUN and cause an immediate VMEXIT with exit code VMEXIT_INVALID if it is invalid, as specified in the APM, volume 2: "Nested Paging and VMRUN/VMEXIT." Fixes: 3d6368ef580a ("KVM: SVM: Add VMRUN handler") Signed-off-by: Jim Mattson <jmattson@google.com> Link: https://patch.msgid.link/20260407190343.325299-4-jmattson@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-14KVM: x86: nSVM: Clear VMCB_NPT clean bit when updating hPAT from guest modeJim Mattson
When running an L2 guest and writing to MSR_IA32_CR_PAT, the host PAT value is stored in both vmcb01's g_pat field and vmcb02's g_pat field, but the clean bit was only being cleared for vmcb02. Introduce the helper vmcb_set_gpat() which sets vmcb->save.g_pat and marks the VMCB dirty for VMCB_NPT. Use this helper in both svm_set_msr() for updating vmcb01 and in nested_vmcb02_compute_g_pat() for updating vmcb02, ensuring both VMCBs' NPT fields are properly marked dirty. Fixes: 4995a3685f1b ("KVM: SVM: Use a separate vmcb for the nested L2 guest") Signed-off-by: Jim Mattson <jmattson@google.com> Link: https://patch.msgid.link/20260407190343.325299-3-jmattson@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-14KVM: x86: Define KVM_X86_QUIRK_NESTED_SVM_SHARED_PATJim Mattson
Define a quirk to control whether nested SVM shares L1's PAT with L2 (legacy behavior) or gives L2 its own independent gPAT (correct behavior per the APM). When the quirk is enabled (default), L2 shares L1's PAT, preserving the legacy KVM behavior. When userspace disables the quirk, KVM correctly virtualizes the PAT for nested SVM guests, giving L2 a separate gPAT as specified in the AMD architecture. Signed-off-by: Jim Mattson <jmattson@google.com> Link: https://patch.msgid.link/20260407190343.325299-2-jmattson@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-14ARM: dts: socfpga: arria10: Increase JFFS2 rootfs partition sizeNiravkumar L Rabara
Increase the JFFS2 partition size to support larger root filesystem. Also fix the partition label to match the actual start address. Signed-off-by: Niravkumar L Rabara <niravkumar.l.rabara@altera.com> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2026-05-14powerpc/time: Remove redundant preempt_disable|enable() calls from ↵Sayali Patil
arch_irq_work_raise() A kernel panic is observed when handling machine check exceptions from real mode. BUG: Unable to handle kernel data access on read at 0xc00000006be21300 Oops: Kernel access of bad area, sig: 11 [#1] MSR: 8000000000001003 <SF,ME,RI,LE> CR: 88222248 XER: 00000005 CFAR: c00000000003ffc4 DAR: c00000006be21300 DSISR: 40000000 IRQMASK: 0 NIP [c000000000029e40] arch_irq_work_raise+0x10/0x70 LR [c00000000003ffc8] machine_check_queue_event+0xa8/0x150 Call Trace: [c0000000179d3c70] [c00000000003ff64] machine_check_queue_event+0x44/0x150 [c0000000179d3d30] [c0000000000084e0] machine_check_early_common+0x1f0/0x2c0 The crash occurs because arch_irq_work_raise() calls preempt_disable() from machine check exception (MCE) handlers running in real mode. In this context, accessing the preempt_count can fault, leading to the panic. The preempt_disable()/preempt_enable() pair in arch_irq_work_raise() was originally added by commit 0fe1ac48bef0 ("powerpc/perf_event: Fix oops due to perf_event_do_pending call") to avoid races while raising irq work from exception context. Later, commit 471ba0e686cb ("irq_work: Do not raise an IPI when queueing work on the local CPU") added preemption protection in irq_work_queue() path, while commit 20b876918c06 ("irq_work: Use per cpu atomics instead of regular atomics") added equivalent protection in irq_work_queue_on() before reaching arch_irq_work_raise(): irq_work_queue() / irq_work_queue_on() -> preempt_disable() -> __irq_work_queue_local() -> irq_work_raise() -> arch_irq_work_raise() As a result, callers other than mce_irq_work_raise() already execute with preemption disabled, making the additional preempt_disable()/preempt_enable() pair in arch_irq_work_raise() redundant. The arch_irq_work_raise() function executes in NMI context when called from MCE handler. Hence we will not be preempted or scheduled out since we are in NMI context with MSR[EE]=0. Therefore, it is safe to remove the preempt_disable()/preempt_enable() calls from here. Remove it to avoid accessing preempt_count from real mode context. Fixes: cc15ff327569 ("powerpc/mce: Avoid using irq_work_queue() in realmode") Suggested-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Acked-by: Shrikanth Hegde <sshegde@linux.ibm.com> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Signed-off-by: Sayali Patil <sayalip@linux.ibm.com> [Maddy: Fixed the commit title] Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260513081413.222490-1-sayalip@linux.ibm.com
2026-05-13riscv: misaligned: Make enabling delegation depend on NONPORTABLEVivian Wang
The unaligned access emulation code in Linux has various deficiencies. For example, it doesn't emulate vector instructions [1] [2], and doesn't emulate KVM guest accesses. Therefore, requesting misaligned exception delegation with SBI FWFT actually regresses vector instructions' and KVM guests' behavior. Until Linux can handle it properly, guard these sbi_fwft_set() calls behind RISCV_SBI_FWFT_DELEGATE_MISALIGNED, which in turn depends on NONPORTABLE. Those who are sure that this wouldn't be a problem can enable this option, perhaps getting better performance. The rest of the existing code proceeds as before, except as if SBI_FWFT_MISALIGNED_EXC_DELEG is not available, to handle any remaining address misaligned exceptions on a best-effort basis. The KVM SBI FWFT implementation is also not touched, but it is disabled if the firmware emulates unaligned accesses. Cc: stable@vger.kernel.org Fixes: cf5a8abc6560 ("riscv: misaligned: request misaligned exception from SBI") Reported-by: Songsong Zhang <U2FsdGVkX1@gmail.com> # KVM Link: https://lore.kernel.org/linux-riscv/38ce44c1-08cf-4e3f-8ade-20da224f529c@iscas.ac.cn/ [1] Link: https://lore.kernel.org/linux-riscv/b3cfcdac-0337-4db0-a611-258f2868855f@iscas.ac.cn/ [2] Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20260401-riscv-misaligned-dont-delegate-v2-1-5014a288c097@iscas.ac.cn Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-05-13riscv: cfi: reduce shadow stack size limit from 4GB to 2GBZong Li
Follow the ARM64 GCS (Guarded Control Stack) implementation approach by reducing the shadow stack size allocation from min(RLIMIT_STACK, 4GB) to min(RLIMIT_STACK/2, 2GB). See commit 506496bcbb42 ("arm64/gcs: Ensure that new threads have a GCS") Rationale: 1. Shadow stacks only store return addresses (8 bytes per entry), not local variables, function parameters, or saved registers. A 2GB shadow stack is far more than sufficient for any practical application, even with extremely deep recursion. Using half the size maintains adequate margin while being more resource-efficient. 2. On memory-constrained systems (e.g., platforms with only 4GB of physical memory, which is a common configuration), allocating 4GB of virtual address space for shadow stack per process/thread can lead to virtual memory allocation failures when the overcommit mode is set to OVERCOMMIT_GUESS or OVERCOMMIT_NEVER: Error: "__vm_enough_memory: not enough memory for the allocation" This reduces virtual address space consumption by 50% while maintaining more than adequate space for return address storage. Signed-off-by: Zong Li <zong.li@sifive.com> Link: https://patch.msgid.link/20260428024105.645162-1-zong.li@sifive.com [pjw@kernel.org: clean up patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-05-13mm/page_alloc: fix initialization of tags of the huge zero folio with ↵David Hildenbrand (Arm)
init_on_free __GFP_ZEROTAGS semantics are currently a bit weird, but effectively this flag is only ever set alongside __GFP_ZERO and __GFP_SKIP_KASAN. If we run with init_on_free, we will zero out pages during __free_pages_prepare(), to skip zeroing on the allocation path. However, when allocating with __GFP_ZEROTAG set, post_alloc_hook() will consequently not only skip clearing page content, but also skip clearing tag memory. Not clearing tags through __GFP_ZEROTAGS is irrelevant for most pages that will get mapped to user space through set_pte_at() later: set_pte_at() and friends will detect that the tags have not been initialized yet (PG_mte_tagged not set), and initialize them. However, for the huge zero folio, which will be mapped through a PMD marked as special, this initialization will not be performed, ending up exposing whatever tags were still set for the pages. The docs (Documentation/arch/arm64/memory-tagging-extension.rst) state that allocation tags are set to 0 when a page is first mapped to user space. That no longer holds with the huge zero folio when init_on_free is enabled. Fix it by decoupling __GFP_ZEROTAGS from __GFP_ZERO, passing to tag_clear_highpages() whether we want to also clear page content. Invert the meaning of the tag_clear_highpages() return value to have clearer semantics. Reproduced with the huge zero folio by modifying the check_buffer_fill arm64/mte selftest to use a 2 MiB area, after making sure that pages have a non-0 tag set when freeing (note that, during boot, we will not actually initialize tags, but only set KASAN_TAG_KERNEL in the page flags). $ ./check_buffer_fill 1..20 ... not ok 17 Check initial tags with private mapping, sync error mode and mmap memory not ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory ... This code needs more cleanups; we'll tackle that next, like decoupling __GFP_ZEROTAGS from __GFP_SKIP_KASAN. [akpm@linux-foundation.org: s/__GPF_ZERO/__GFP_ZERO/, per David] Link: https://lore.kernel.org/20260421-zerotags-v2-1-05cb1035482e@kernel.org Fixes: adfb6609c680 ("mm/huge_memory: initialise the tags of the huge zero folio") Signed-off-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Lance Yang <lance.yang@linux.dev> Cc: Brendan Jackman <jackmanb@google.com> Cc: Dev Jain <dev.jain@arm.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Liam Howlett <liam@infradead.org> Cc: Lorenzo Stoakes (Oracle) <ljs@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Will Deacon <will@kernel.org> Cc: Zi Yan <ziy@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-05-13KVM: SEV: Allocate only as many bytes as needed for temp crypt buffersSean Christopherson
When using a temporary buffer to {de,en}crypt unaligned memory for debug, allocate only the number of bytes that are needed instead of allocating an entire page. The most common case for unaligned accesses will be reading or writing less than 16 bytes. Link: https://patch.msgid.link/20260501203537.2120074-7-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: SEV: Rewrite logic to {de,en}crypt memory for debugSean Christopherson
Wholesale rewrite the guts of the debug {de,en}crypt flows, as the existing code is broken, e.g. doesn't handle cases where the access isn't naturally sized and aligned, and is so wildly flawed that attempting to salvage the current code in an iterative fashion would be more risky than a rewrite. E.g. when encrypting 9 bytes at offset 8, KVM needs to _decrypt_ destination[31:0] into a temporary buffer, buffer[31:0], then copy 9 bytes from source[8:0] to buffer[16:8], then encrypt buffer[31:0] back into destination[31:0]. The current code only ever copies 16 bytes, and bizarrely uses a temporary buffer for the source as well. To keep the code easier to read and maintain, send the unaligned cases down dedicated "slow" paths instead of trying to mix and match the possible combinations in one helper. For now, preserve the basic approach of the current code, e.g. allocate an entire page for the temporary buffer, to minimize unwanted changes in functionality. Link: https://patch.msgid.link/20260501203537.2120074-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: SEV: Add helper function to pin/unpin a single pageSean Christopherson
Add helpers to pin/unpin a single page, and use it in all flows that pin exactly one page. None of the single-page users actually check that the correct number of pages was pinned, which is functionally ok, but visually jarring, especially in the decrypt/encrypt flow, which separately pins two pages, but uses a single variable to track how pages were pinned each time. Again, it's functionally ok since core mm guarantees exactly one page will be pinned on success, but it's ugly. Opportunistically use page_to_phys() instead of open coding an equivalent via page_to_pfn(). Note, all users of the single-page helper pre-validate the address and length, i.e. don't rely on the sanity check in sev_pin_memory(). No functional change intended. Link: https://patch.msgid.link/20260501203537.2120074-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: SEV: Explicitly validate the dst buffer for debug operationsSean Christopherson
When encrypting/decrypting guest memory, explicitly check that the destination is non-NULL and doesn't wrap instead of subtly relying on sev_pin_memory() to perform the check. This will allow adding and using a more focused single-page pinning helper. Link: https://patch.msgid.link/20260501203537.2120074-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-14ARM: dts: zte: Add D-Link DWR-932M supportStefan Dösinger
This adds base DT definition for zx297520v3 and one board that consumes it. The stock kernel does not use the armv7 timer, but it seems to work fine. The board has other board-specific timers that would need a driver and I see no reason to bother with them since the arm standard timer works. The caveat is the non-standard GIC setup needed to handle the timer's level-low PPI. This is the responsibility of the boot loader and documented in Documentation/arch/arm/zte/zx297520v3.rst. Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com> --- Changes in v8: Remove redundant label, use "arm,pl011" for uart0 and 2 too. v6: Squash board + timer + uart patches into one v5: Prepend the SoC name in the device specific DTS filename. v4: Declare all uarts Remove the UART aliases for now. I can revisit this when I get my hands on a board that exposes two UARTs.
2026-05-13ARM: zte: Add zx297520v3 platform supportStefan Dösinger
This SoC is used in low end LTE-to-WiFi routers, for example some D-Link DWR 932 revisions, ZTE K10, ZLT S10 4G, but also models that are branded and sold by ISPs themselves. They are widespread in Africa, China, Russia and Eastern Europe. This SoC is a relative of the zx296702 and zx296718 that had some upstream support until commit 89d4f98ae90d ("ARM: remove zte zx platform"). Reviewed-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com> --- Patch changelog: v8: * Select ARM_PSCI_FW (Sashiko). This is an issue make defconfig pointed out in the last patch in this series. The board does not have PSCI firmware as far as I can tell, but the ARM_GIC_V3 option indirectly assumes ARM_PSCI_FW is enabled. * Include <linux/init.h> in the board file for __initdata (Sashiko), removed other includes copypasted from another platform that aren't needed. Let's see if Sashiko agrees. * Add the SoC documentation to the documentation index (Sashiko) * Add the SoC documentation to MAINTAINERS (Sashiko) * Removed redundant if ARCH_ZTE (Sashiko) * Point towards a sane (USB-Only) U-Boot and modify the example code for booting from NAND to detect already fixed GIC setups.
2026-05-13Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds
Pull kvm fixes from Paolo Bonzini: "arm64: - Add the pKVM side of the workaround for ARM's erratum 4193714, provided that the EL3 firmware does its part of the job. KVM will refuse to initialise otherwise - Correctly handle 52bit VAs for guest EL2 stage-1 translations when running under NV with E2H==0 - Correctly deal with permission faults in guest_memfd memslots - Fix the steal-time selftest after the infrastructure was reworked - Make sure the host cannot pass a non-sensical clock update to the EL2 tracing infrastructure - Appoint Steffen Eiden as a reviewer in anticipation of the KVM/s390 ability to run arm64 guests, which will inevitably lead to arm64 code being directly used on s390 - Make sure that EL2 is configured with both exception entry and exit being Context Synchronization Events - Handle the current vcpu being NULL on EL2 panic - Fix the selftest_vcpu memcache being empty at the point of donation or sharing - Check that the memcache has enough capacity before engaging on the share/donate path - Fix __deactivate_fgt() to use its parameter rather than a variable in the macro context s390: - Fix array overrun with large amounts of PCI devices x86: - Never use L0's PAUSE loop exiting while L2 is running, since it's unlikely that a nested guest will help solving the hypervisor's spinlock contention - Fix emulation of MOVNTDQA - Fix typo in Xen hypercall tracepoint - Add back an optimization that was left behind when recently fixing a bug - Add module parameter to disable CET, whose implementation seems to have issues. For now it remains enabled by default Generic: - Reject offset causing an unsigned overflow in kvm_reset_dirty_gfn() Documentation: - Update stale links Selftests: - Fix guest_memfd_test with host page size > guest page size" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (22 commits) KVM: VMX: introduce module parameter to disable CET KVM: x86: Swap the dst and src operand for MOVNTDQA KVM: x86: use again the flush argument of __link_shadow_page() KVM: selftests: Ensure gmem file sizes are multiple of host page size Documentation: kvm: update links in the references section of AMD Memory Encryption KVM: nSVM: Never use L0's PAUSE loop exiting while L2 is running KVM: x86: Fix Xen hypercall tracepoint argument assignment KVM: Reject wrapped offset in kvm_reset_dirty_gfn() KVM: arm64: Pre-check vcpu memcache for host->guest donate KVM: arm64: Pre-check vcpu memcache for host->guest share KVM: arm64: Seed pkvm_ownership_selftest vcpu memcache KVM: arm64: Fix __deactivate_fgt macro parameter typo KVM: arm64: Guard against NULL vcpu on VHE hyp panic path KVM: arm64: Make EL2 exception entry and exit context-synchronization events MAINTAINERS: Add Steffen as reviewer for KVM/arm64 KVM: arm64: Remove potential UB on nvhe tracing clock update KVM: selftests: arm64: Fix steal_time test after UAPI refactoring KVM: arm64: Handle permission faults with guest_memfd KVM: arm64: nv: Consider the DS bit when translating TCR_EL2 KVM: arm64: Work around C1-Pro erratum 4193714 for protected guests ...
2026-05-13KVM: TDX: Fix x2APIC MSR handling in tdx_has_emulated_msr()Rick Edgecombe
Rework tdx_has_emulated_msr() to explicitly enumerate the x2APIC MSRs that KVM can emulate, instead of trying to enumerate the MSRs that KVM cannot emulate. Drop the inner switch and list the emulatable x2APIC registers directly in the outer switch's "return true" block. The old code had multiple bugs in the x2APIC range handling. X2APIC_MSR(APIC_ISR + APIC_ISR_NR) was incorrect because APIC_ISR_NR is 0x8, not 0x80, so the X2APIC_MSR() shift lost the lower bits, collapsing each range to a single MSR. IA32_X2APIC_SELF_IPI was also missing from the non-emulatable list. Note, these bugs are relatively benign, as they only affect a guest that is requesting "bogus" emulation. KVM has no visibility into whether or not a guest has enabled #VE reduction, which changes which MSRs the TDX-Module handles itself versus triggering a #VE for the guest to make a TDVMCALL. So maintaining a list of non-emulatable MSRs is fragile. Listing only the MSRs KVM can always emulate sidesteps the problem. Suggested-by: Sean Christopherson <seanjc@google.com> Reported-by: Dmytro Maluka <dmaluka@chromium.org> Closes: https://lore.kernel.org/all/20260318190111.1041924-1-dmaluka@chromium.org Fixes: dd50294f3e3c ("KVM: TDX: Implement callbacks for MSR operations") Assisted-by: Claude:claude-opus-4-6 [based on a diff from Sean, but added missed LVTCMCI case, log] Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://patch.msgid.link/20260410232654.3864196-1-rick.p.edgecombe@intel.com [sean: call out the bugs are relatively benign, expand comment] Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: x86: Make "external SPTE" ops that can fail RET0 static callsSean Christopherson
Define kvm_x86_ops .link_external_spt(), .set_external_spte(), and .free_external_spt() as RET0 static calls so that an unexpected call to a a default operation doesn't consume garbage. Fixes: 77ac7079e66d ("KVM: x86/tdp_mmu: Propagate building mirror page tables") Fixes: 94faba8999b9 ("KVM: x86/tdp_mmu: Propagate tearing down mirror page tables") Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Link: https://patch.msgid.link/20260129011517.3545883-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: TDX: Account all non-transient page allocations for per-TD structuresSean Christopherson
Account all non-transient allocations associated with a single TD (or its vCPUs), as KVM's ABI is that allocations that are active for the lifetime of a VM are accounted. Leave temporary allocations, i.e. allocations that are freed within a single function/ioctl, unaccounted, to again align with KVM's existing behavior, e.g. see commit dd103407ca31 ("KVM: X86: Remove unnecessary GFP_KERNEL_ACCOUNT for temporary variables"). Fixes: 8d032b683c29 ("KVM: TDX: create/destroy VM structure") Fixes: a50f673f25e0 ("KVM: TDX: Do TDX specific vcpu initialization") Cc: stable@vger.kernel.org Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Link: https://patch.msgid.link/20260129011517.3545883-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: x86/mmu: Update iter->old_spte if cmpxchg64 on mirror SPTE "fails"Sean Christopherson
Pass a pointer to iter->old_spte, not simply its value, when setting an external SPTE in __tdp_mmu_set_spte_atomic(), so that the iterator's value will be updated if the cmpxchg64 to freeze the mirror SPTE fails. The bug is currently benign as TDX is mutualy exclusive with all paths that do "local" retry", e.g. clear_dirty_gfn_range() and wrprot_gfn_range(). Fixes: 77ac7079e66d ("KVM: x86/tdp_mmu: Propagate building mirror page tables") Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Link: https://patch.msgid.link/20260129011517.3545883-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13x86/tdx: Use pg_level in TDX APIs, not the TDX-Module's 0-based levelSean Christopherson
Rework the TDX APIs to take the kernel's 1-based pg_level enum, not the TDX-Module's 0-based level. The APIs are _kernel_ APIs, not TDX-Module APIs, and the kernel (and KVM) uses "enum pg_level" literally everywhere. Using "enum pg_level" eliminates ambiguity when looking at the APIs (it's NOT clear that "int level" refers to the TDX-Module's level), and will allow for using existing helpers like page_level_size() when support for hugepages is added to the S-EPT APIs. No functional change intended. Cc: Kai Huang <kai.huang@intel.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: Yan Zhao <yan.y.zhao@intel.com> Cc: Vishal Annapurve <vannapurve@google.com> Cc: Ackerley Tng <ackerleytng@google.com> Acked-by: Kiryl Shutsemau <kas@kernel.org> Reviewed-by: Kai Huang <kai.huang@intel.com> Tested-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Tested-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20260129011517.3545883-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: x86: Drop superfluous caching of KVM_ASYNC_PF_SEND_ALWAYSSean Christopherson
Drop kvm_vcpu_arch.apf.send_always and instead use msr_en_val as the source of truth to reduce the probability of operating on stale data. This fixes flaws where KVM fails to update send_always when APF is explicitly disabled by the guest or implicitly disabled by KVM on INIT. Absent other bugs, the flaws are benign as KVM *shouldn't* consume send_always when PV APF support is disabled. Simply delete the field, as there's zero benefit to maintaining a separate "cache" of the state. Opportunistically turn the enabled vs. disabled logic at the end of kvm_pv_enable_async_pf() into an if-else instead of using an early return, e.g. so that it's more obvious that both paths are "success" paths. Fixes: 6adba5274206 ("KVM: Let host know whether the guest can handle async PF in non-userspace context.") Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://patch.msgid.link/20260406225359.1245490-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: x86: Drop superfluous caching of KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXITSean Christopherson
Drop kvm_vcpu_arch.apf.delivery_as_pf_vmexit and instead use msr_en_val as the source of truth to reduce the probability of operating on stale data. This fixes flaws where KVM fails to update delivery_as_pf_vmexit when APF is explicitly disabled by the guest or implicitly disabled by KVM on INIT. Absent other bugs, the flaws are benign as KVM *shouldn't* consume delivery_as_pf_vmexit when PV APF support is disabled. Simply delete the field, as there's zero benefit to maintaining a separate "cache" of the state. Fixes: 52a5c155cf79 ("KVM: async_pf: Let guest support delivery of async_pf from guest mode") Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://patch.msgid.link/20260406225359.1245490-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: x86: Don't leave APF half-enabled on bad APF data GPAEthan Yang
kvm_pv_enable_async_pf() updates vcpu->arch.apf.msr_en_val before initializing the APF data gfn_to_hva cache. If userspace provides an invalid GPA, kvm_gfn_to_hva_cache_init() fails, but msr_en_val stays enabled and leaves APF state half-initialized. Later APF paths can then try to use the empty cache and trigger WARN_ON() in kvm_read_guest_offset_cached(). Determine the new APF enabled state from the incoming MSR value, do cache initialization first on the enable path, and commit msr_en_val only after successful initialization. Keep the disable path behavior unchanged. Reported-by: syzbot+bc0e18379a290e5edfe4@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bc0e18379a290e5edfe4 Fixes: 344d9588a9df ("KVM: Add PV MSR to enable asynchronous page faults delivery.") Link: https://lore.kernel.org/r/aHfD3MczrDpzDX9O@google.com Suggested-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Ethan Yang <ethan.yang.kernel@gmail.com> [sean: don't bother with a local "enable" variable] Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://patch.msgid.link/20260406225359.1245490-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: x86: Rate-limit global clock updates on vCPU loadLei Chen
commit 446fcce2a52b ("Revert "x86: kvm: rate-limit global clock updates"") dropped the rate limiting for KVM_REQ_GLOBAL_CLOCK_UPDATE. As a result, kvm_arch_vcpu_load() can queue global clock update requests every time a vCPU is scheduled when the master clock is disabled or when the vCPU is loaded for the first time. Restore the throttling with a per-VM ratelimit state and gate KVM_REQ_GLOBAL_CLOCK_UPDATE through __ratelimit(), so frequent vCPU scheduling does not generate a steady stream of redundant clock update requests. Fixes: 446fcce2a52b ("Revert "x86: kvm: rate-limit global clock updates"") Signed-off-by: Lei Chen <lei.chen@smartx.com> Reported-by: Jaroslav Pulchart <jaroslav.pulchart@gooddata.com> Closes: https://lore.kernel.org/all/CAK8fFZ5gY8_Mw2A=iZVFNVKQNrXQzVsn-HTd+Me9K6ZfmdgA+Q@mail.gmail.com/ Link: https://patch.msgid.link/20260409142226.2581-1-lei.chen@smartx.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT pathAshutosh Desai
In sev_dbg_crypt(), the per-iteration transfer length is bounded by the source page offset (PAGE_SIZE - s_off) but not by the destination page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt path (__sev_dbg_encrypt_user) performs a read-modify-write using a single-page intermediate buffer (dst_tpage): 1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16) before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE, the PSP writes beyond the end of the 4096-byte dst_tpage allocation. 2. The subsequent memcpy()/copy_from_user() into page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition. Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE - the PSP is instructed to write round_up(4097, 16) = 4112 bytes to a 4096-byte buffer. Fix by also bounding len by (PAGE_SIZE - d_off), the same check that sev_send_update_data() already performs for its single-page guest region. ================================================================== BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd] Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214 CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: <TASK> dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [kvm] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint Fixes: 24f41fb23a39 ("KVM: SVM: Add support for SEV DEBUG_DECRYPT command") Fixes: 7d1594f5d94b ("KVM: SVM: Add support for SEV DEBUG_ENCRYPT command") Cc: stable@vger.kernel.org Signed-off-by: Ashutosh Desai <ashutoshdesai993@gmail.com> [sean: add sample KASAN splat, Fixes, and stable@] Link: https://patch.msgid.link/20260501203537.2120074-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: SEV: Don't advertise VM types that are disabled by firmwareTycho Andersen
As called out in a footnote for a recent SNP vulnerability[1], it is possible for a specific flavor of SEV+ to be disabled by the firmware even when the flavor is fully supported by the CPU and platform: Applying mitigation CVE-2025-48514 will result in disabling SEV-ES when SEV-SNP is enabled. Restrict KVM's set of supported VM types based on the VM types that are fully supported by firmware to avoid over-reporting what KVM can actually support. Like KVM's handling of ASID space exhaustion, don't modify KVM's CPUID capabilities, as the CPU/platform still supports the underlying technology and clearing e.g. SEV_ES while advertising SEV_SNP would confuse KVM and userspace. Link: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3023.html [1] Link: https://lore.kernel.org/all/aZyLIWtffvEnmtYh@google.com Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> [sean: rewrite changelog to provide details on why/how this can happen] Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Tested-by: Tycho Andersen (AMD) <tycho@kernel.org> Link: https://patch.msgid.link/20260416232329.3408497-7-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: SEV: Don't advertise support for unusable VM typesSean Christopherson
Commit 0aa6b90ef9d7 ("KVM: SVM: Add support for allowing zero SEV ASIDs") made it possible to make it impossible to use SEV VMs by not allocating them any ASIDs. Commit 6c7c620585c6 ("KVM: SEV: Add SEV-SNP CipherTextHiding support") did the same thing for SEV-ES. Do not export KVM_X86_SEV(_ES)_VM as supported types if in either of these situations, so that userspace can use them to determine what is actually supported by the current kernel configuration. Also move the buildup to a local variable so it is easier to add additional masking in future patches. Link: https://lore.kernel.org/all/aZyLIWtffvEnmtYh@google.com/ Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> [sean: land code in sev_hardware_setup()] Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Tested-by: Tycho Andersen (AMD) <tycho@kernel.org> Link: https://patch.msgid.link/20260416232329.3408497-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: SEV: Consolidate logic for printing state of SEV{,-ES,-SNP} enablingSean Christopherson
Add a helper to print enabled/unusable/disabled for SEV+ VM types in anticipation of SNP also being subjecting to "unusable" logic. No functional change intended. Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Tested-by: Tycho Andersen (AMD) <tycho@kernel.org> Link: https://patch.msgid.link/20260416232329.3408497-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-19 19:15:46 +0000