summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2026-05-03KVM: x86: Do IRR scan in __kvm_apic_update_irr even if PIR is emptyPaolo Bonzini
Fall back to apic_find_highest_vector() when PID.ON is set but PIR turns out to be empty, to correctly report the highest pending interrupt from the existing IRR. In a nested VM stress test, the following WARNING fires in vmx_check_nested_events() when kvm_cpu_has_interrupt() reports a pending interrupt but the subsequent kvm_apic_has_interrupt() (which invokes vmx_sync_pir_to_irr() again) returns -1: WARNING: CPU: 99 PID: 57767 at arch/x86/kvm/vmx/nested.c:4449 vmx_check_nested_events+0x6bf/0x6e0 [kvm_intel] Call Trace: kvm_check_and_inject_events vcpu_enter_guest.constprop.0 vcpu_run kvm_arch_vcpu_ioctl_run kvm_vcpu_ioctl __x64_sys_ioctl do_syscall_64 entry_SYSCALL_64_after_hwframe The root cause is a race between vmx_sync_pir_to_irr() on the target vCPU and __vmx_deliver_posted_interrupt() on a sender vCPU. The sender performs two individually-atomic operations that are not a single transaction: 1. pi_test_and_set_pir(vector) -- sets the PIR bit 2. pi_test_and_set_on() -- sets PID.ON The following interleaving triggers the bug: Sender vCPU (IPI): Target vCPU (1st sync_pir_to_irr): B1: set PIR[vector] A1: pi_clear_on() A2: pi_harvest_pir() -> sees B1 bit A3: xchg() -> consumes bit, PIR=0 (1st sync returns correct max_irr) B2: set PID.ON = 1 Target vCPU (2nd sync_pir_to_irr): C1: pi_test_on() -> TRUE (from B2) C2: pi_clear_on() -> ON=0 C3: pi_harvest_pir() -> PIR empty C4: *max_irr = -1, early return IRR NOT SCANNED The interrupt is not lost (it resides in the IRR from the first sync and is recovered on the next vcpu_enter_guest() iteration), but the incorrect max_irr causes a spurious WARNING and a wasted L2 VM-Enter/VM-Exit cycle. Fixes: b41f8638b9d3 ("KVM: VMX: Isolate pure loads from atomic XCHG when processing PIR") Reported-by: Farrah Chen <farrah.chen@intel.com> Analyzed-by: Chenyi Qiang <chenyi.qiang@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Sean Christopherson <seanjc@google.com> Link: https://lore.kernel.org/kvm/20260428070349.1633238-1-chenyi.qiang@intel.com/T/ Link: https://patch.msgid.link/20260503201703.108231-2-pbonzini@redhat.com/ Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-05-03KVM: x86: check for nEPT/nNPT in slow flush hypercallsPaolo Bonzini
Checking is_guest_mode(vcpu) is incorrect, because translate_nested_gpa() is only valid if an L2 guest is running *with nested EPT/NPT enabled*. Instead use the same condition as translate_nested_gpa() itself. Cc: stable@vger.kernel.org Reviewed-by: Sean Christopherson <seanjc@google.com> Fixes: aee738236dca ("KVM: x86: Prepare kvm_hv_flush_tlb() to handle L2's GPAs", 2022-11-18) Link: https://patch.msgid.link/20260503200905.106077-1-pbonzini@redhat.com/ Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-05-03Merge tag 'sh-for-v7.1-tag2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/glaubitz/sh-linux Pull sh fix from John Paul Adrian Glaubitz: "The ZERO_PAGE consolidation in v7.1, introduced a regression on sh which made these systems unbootable. The problem was that on sh, the initial boot parameters were previously referenced as an array and after 6215d9f4470f ("arch, mm: consolidate empty_zero_page"), they were referenced as a pointer which caused wrong code generation and boot hang. This changes the declaration back to being an array which fixes the boot hang" * tag 'sh-for-v7.1-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/glaubitz/sh-linux: sh: Fix fallout from ZERO_PAGE consolidation
2026-05-03sh: Fix fallout from ZERO_PAGE consolidationMike Rapoport (Microsoft)
Consolidation of empty_zero_page declarations broke boot on sh. sh stores its initial boot parameters in a page reserved in arch/sh/kernel/head_32.S. Before commit 6215d9f4470f ("arch, mm: consolidate empty_zero_page") this page was referenced in C code as an array and after that commit it is referenced as a pointer. This causes wrong code generation and boot hang. Declare boot_params_page as an array to fix the issue. Reported-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Tested-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Fixes: 6215d9f4470f ("arch, mm: consolidate empty_zero_page") Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Artur Rojek <contact@artur-rojek.eu> Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
2026-05-01riscv: mm: Fixup no5lvl failure when vaddr is invalidGuo Ren (Alibaba DAMO Academy)
Unlike no4lvl, no5lvl still continues to detect satp, which requires va=pa mapping. When pa=0x800000000000, no5lvl would fail in Sv48 mode due to an illegal VA value of 0x800000000000. So, prevent detecting the satp flow for no5lvl, when vaddr is invalid. Add the is_vaddr_valid() function for checking. Fixes: 26e7aacb83df ("riscv: Allow to downgrade paging mode from the command line") Cc: Alexandre Ghiti <alexghiti@rivosinc.com> Cc: Björn Töpel <bjorn@rivosinc.com> Signed-off-by: Guo Ren (Alibaba DAMO Academy) <guoren@kernel.org> Tested-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Link: https://patch.msgid.link/20260125055212.433163-1-guoren@kernel.org [pjw@kernel.org: cleaned up commit message] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-05-01riscv: Fix register corruption from uninitialized cregs on errorMichael Neuling
compat_riscv_gpr_set() calls cregs_to_regs() unconditionally, even when user_regset_copyin() fails. Since cregs is an uninitialized stack variable, a copyin failure causes uninitialized stack data to be written into the target task's pt_regs, corrupting its register state and potentially leaking kernel stack contents. compat_restore_sigcontext() has the same issue: it calls cregs_to_regs() even when __copy_from_user() fails, leading to the same corruption of the signal-returning task's register state on error. Only call cregs_to_regs() when the user copy succeeds. Fixes: 4608c159594f ("riscv: compat: ptrace: Add compat_arch_ptrace implement") Fixes: 7383ee05314b ("riscv: compat: signal: Add rt_frame implementation") Signed-off-by: Michael Neuling <mikey@neuling.org> Assisted-by: Cursor:claude-4.6-opus-high-thinking Link: https://patch.msgid.link/20260501062320.2339562-1-mikey@neuling.org Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-05-01Merge tag 'arm64-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Catalin Marinas: - Avoid writing an uninitialised stack variable to POR_EL0 on sigreturn if the poe_context record is absent - Reserve one more page for the early 4K-page kernel mapping to cover the extra [_text, _stext) split introduced by the non-executable read-only mapping - Force the arch_local_irq_*() wrappers to be __always_inline so that noinstr entry and idle paths cannot call out-of-line, instrumentable copies - Fix potential sign extension in the arm64 SCS unwinder's DWARF advance_loc4 decoding - Tolerate arm64 ACPI platforms with only WFI and no deeper PSCI idle states, restoring cpuidle registration on such systems - Include the UAPI <asm/ptrace.h> header in the arm64 GCS libc test rather than carrying a duplicate struct user_gcs definition (the original #ifdef NT_ARM_GCS was wrong to cover the structure definition as it would be masked out if the toolchain defined it) * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: signal: Preserve POR_EL0 if poe_context is missing arm64: Reserve an extra page for early kernel mapping kselftest/arm64: Include <asm/ptrace.h> for user_gcs definition ACPI: arm64: cpuidle: Tolerate platforms with no deep PSCI idle states arm64/irqflags: __always_inline the arch_local_irq_*() helpers arm64/scs: Fix potential sign extension issue of advance_loc4
2026-05-01Merge tag 's390-7.1-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Alexander Gordeev: - Reject zero-length writes from userspace that corrupt Debug Facility buffers - Replace one s390 PCI maintainer - Remove SCLP_OFB Kconfig option and enable the guarded code unconditionally - Replace incorrect use of phys_to_folio() to virt_to_folio() in do_secure_storage_access() * tag 's390-7.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/mm: Fix phys_to_folio() usage in do_secure_storage_access() s390/sclp: Remove SCLP_OFB Kconfig option MAINTAINERS: Replace one of the maintainers for s390/pci s390/debug: Reject zero-length input in debug_input_flush_fn() s390/debug: Reject zero-length input before trimming a newline
2026-05-01parisc: Fix 64-bit kernel build when CONFIG_COMPAT=nHelge Deller
VDSO32_SYMBOL() is used in signal.c, defining the value to zero avoids liker issues when CONFIG_COMPAT=n. Signed-off-by: Helge Deller <deller@gmx.de>
2026-05-01ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpointJihed Chaibi
The cpu_endpoint in mcasp0 specifies the TLV320AIC3106 codec as the bitclock and frame master, but the phandles point to the codec's port node (codec_port) rather than its endpoint node (codec_endpoint). audio-graph-card calls simple_util_parse_daifmt() with ep_codec set to the endpoint node (codec_endpoint). The function resolves the bitclock-master phandle and checks whether it equals ep_codec. Since codec_port is the parent of codec_endpoint, not the endpoint itself, the comparison always evaluates to false. This causes the mcasp0 CPU side to be silently configured as bitclock and frame master instead of the codec, which is the opposite of the intended configuration. Fix by pointing bitclock-master and frame-master to codec_endpoint. Fixes: e5f89dbdebc5 ("ARM: dts: am335x-sl50: use audio-graph-card for sound") Signed-off-by: Jihed Chaibi <jihed.chaibi.dev@gmail.com> Link: https://patch.msgid.link/20260325223411.123666-1-jihed.chaibi.dev@gmail.com Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
2026-05-01arm64: signal: Preserve POR_EL0 if poe_context is missingKevin Brodsky
Commit 2e8a1acea859 ("arm64: signal: Improve POR_EL0 handling to avoid uaccess failures") delayed the write to POR_EL0 in rt_sigreturn to avoid spurious uaccess failures. This change however relies on the poe_context frame record being present: on a system supporting POE, calling sigreturn without a poe_context record now results in writing arbitrary data from the kernel stack into POR_EL0. Fix this by adding a __valid_fields member to struct user_access_state, and zeroing the struct on allocation. restore_poe_context() then indicates that the por_el0 field is valid by setting the corresponding bit in __valid_fields, and restore_user_access_state() only touches POR_EL0 if there is a valid value to set it to. This is in line with how POR_EL0 was originally handled; all frame records are currently optional, except fpsimd_context. To ensure that __valid_fields is kept in sync, fields (currently just por_el0) are now accessed via accessors and prefixed with __ to discourage direct access. Fixes: 2e8a1acea859 ("arm64: signal: Improve POR_EL0 handling to avoid uaccess failures") Cc: <stable@vger.kernel.org> Reported-by: Will Deacon <will@kernel.org> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2026-05-01arm64: Reserve an extra page for early kernel mappingZhaoyang Huang
The final part of [data, end) segment may overflow into the next page of init_pg_end[1] which is the gap page before early_init_stack[2]: [1] crash_arm64_v9.0.1> vtop ffffffed00601000 VIRTUAL PHYSICAL ffffffed00601000 83401000 PAGE DIRECTORY: ffffffecffd62000 PGD: ffffffecffd62da0 => 10000000833fb003 PMD: ffffff80033fb018 => 10000000833fe003 PTE: ffffff80033fe008 => 68000083401f03 PAGE: 83401000 PTE PHYSICAL FLAGS 68000083401f03 83401000 (VALID|SHARED|AF|NG|PXN|UXN) PAGE PHYSICAL MAPPING INDEX CNT FLAGS fffffffec00d0040 83401000 0 0 1 4000 reserved [2] ffffffed002c8000 (r) __pi__data ffffffed0054e000 (d) __pi___bss_start ffffffed005f5000 (b) __pi_init_pg_dir ffffffed005fe000 (b) __pi_init_pg_end ffffffed005ff000 (B) early_init_stack ffffffed00608000 (b) __pi__end For 4K pages, the early kernel mapping may use 2MB block entries but the kernel segments are only 64KB aligned. Segment boundaries that fall within a 2MB block therefore require a PTE table so that different attributes can be applied on either side of the boundary. KERNEL_SEGMENT_COUNT still correctly counts the five permanent kernel VMAs registered by declare_kernel_vmas(). However, since commit 5973a62efa34 ("arm64: map [_text, _stext) virtual address range non-executable+read-only"), the early mapper also maps [_text, _stext) separately from [_stext, _etext). This adds one more early-only split and can require one more page-table page than the existing EARLY_SEGMENT_EXTRA_PAGES allowance reserves. Increase the 4K-page early mapping allowance by one page to cover that additional split. Fixes: 5973a62efa34 ("arm64: map [_text, _stext) virtual address range non-executable+read-only") Assisted-by: TRAE:GLM-5.1 Suggested-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com> [catalin.marinas@arm.com: rewrote part of the commit log] [catalin.marinas@arm.com: expanded the code comment] Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2026-05-01KVM: x86/mmu: rename and clarify BYTE_MASKPaolo Bonzini
The BYTE_MASK macro is the central point of the black magic in update_permission_bitmask(). Rename it to something that relates to how it is used, and add a comment explaining how it works. Using shifts instead of powers of two was actually suggested by David Hildenbrand back in 2017 for clarity[1] but I evidently forgot his suggestion when applying to kvm.git. [1] https://lore.kernel.org/kvm/e4b5df86-31ae-2f4e-0666-393753e256df@redhat.com/ Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-05-01KVM: x86/mmu: merge make_spte_{non,}executablePaolo Bonzini
As the logic will become more complicated with the introduction of MBEC, at least write it only once. Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-04-30riscv: errata: Fix bitwise vs logical AND in MIPS errata patchingMichael Neuling
The condition checking whether a specific errata needs patching uses logical AND (&&) instead of bitwise AND (&). Since logical AND only checks that both operands are non-zero, this causes all errata patches to be applied whenever any single errata is detected, rather than only applying the matching one. The SiFive errata implementation correctly uses bitwise AND for the same check. Fixes: 0b0ca959d206 ("riscv: errata: Fix the PAUSE Opcode for MIPS P8700") Signed-off-by: Michael Neuling <mikey@neuling.org> Assisted-by: Cursor:claude-4.6-opus-high-thinking Link: https://patch.msgid.link/20260409091143.1348853-2-mikey@neuling.org [pjw@kernel.org: fixed checkpatch warning] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-30riscv: cpufeature: Drop this_hwcap clear in T-Head vector workaroundHui Wang
The variable this_hwcap is initialized to 0 for each loop, it is not necessary to do the bit clearance since this_hwcap is still 0 at this point, clearing the source_isa is enough here. Signed-off-by: Hui Wang <hui.wang@canonical.com> Link: https://patch.msgid.link/20260430045350.22213-1-hui.wang@canonical.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-30s390/pai: Disable duplicate read of kernel PAI counter valueThomas Richter
The PAI crypto counter design allows for user space and kernel space PAI counter increment recording. This is achieved by splitting the recording page in half. The upper part of the 4KB page records user space increments of PAI crypto counter and the lower half records kernel space increments. The page itself looks like: lowcore ptr ---> ++++++++++++++++++++++++ |user space area | +----------------------+ |kernel space area | ++++++++++++++++++++++++ User space and kernel space entries are handled via a kernel_offset value when wrting. For PAI crypto counters this offset is 2048 or half of a page size. For PAI NNPA counter design this distinction was not needed. There is no user and kernel space part for the page pointed to by lowcore. The set up is: lowcore ptr ---> ++++++++++++++++++++++++ |user + kernel space | |area | | | ++++++++++++++++++++++++ There is always only one counter value recorded and saved. Depending on number of CPUs and machine load, the number of PAI NNPA counter increment differs between counting (perf stat) and recording (perf record). The number reported by sampling was double the number shown by counting. This was caused by a double read of the PAI NNPA values in function pai_copy(). The first part of that function reads the kernel space part. The offset into the kernel page part must be larger than zero. The second part of that function reads the user space part, which begins of offset zero. This works fine for PAI crypto counters. It fails for PAI NNPA counters because the PMU device driver does not support that feature and has a kernel_offset value of 0x0. Executing both user and kernel space read out might end up reading user space value twice. For the PAI NNPA PMU prohibit the kernel space part read out. Cc: stable@vger.kernel.org Fixes: f12473541356 ("s390/pai_crypto: Rename paicrypt_copy() to pai_copy()") Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Reviewed-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-04-30KVM: x86/mmu: remove SPTE_EPT_*Paolo Bonzini
spte.h is already including vmx.h, use the constants it defines. Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-04-30KVM: x86/mmu: shuffle high bits of SPTEs in preparation for MBECPaolo Bonzini
Access tracking will need to save bit 10 when MBEC is enabled. Right now it is simply shifting the R and X bits into bits 54 and 56, but bit 10 would not fit with the same scheme. Reorganize the high bits so that access tracking will use bits 52, 54 and 62. As a side effect, the free bits are compacted slightly, with 56-59 still unused. Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-04-30KVM: x86/mmu: free up bit 10 of PTEs in preparation for MBECJon Kohler
Update SPTE_MMIO_ALLOWED_MASK to allow EPT user executable (bit 10) to be treated like EPT RWX bit2:0, as when mode-based execute control is enabled, bit 10 can act like a "present" bit. Likewise do not include it in FROZEN_SPTE. No functional changes intended, other than the reduction of the maximum MMIO generation that is stored in page tables. Cc: Kai Huang <kai.huang@intel.com> Signed-off-by: Jon Kohler <jon@nutanix.com> Message-ID: <20251223054806.1611168-4-jon@nutanix.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-04-30KVM: x86/mmu: remove SPTE_PERM_MASKJon Kohler
SPTE_PERM_MASK is no longer referenced by anything in the kernel. Signed-off-by: Jon Kohler <jon@nutanix.com> Message-ID: <20251223054806.1611168-3-jon@nutanix.com> Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-04-30KVM: TDX/VMX: rework EPT_VIOLATION_EXEC_FOR_RING3_LIN into PROT_MASKJon Kohler
EPT exit qualification bit 6 is used when mode-based execute control is enabled, and reflects user executable addresses. Rework name to reflect the intention and add to EPT_VIOLATION_PROT_MASK, which allows simplifying the return evaluation in tdx_is_sept_violation_unexpected_pending a pinch. Rework handling in __vmx_handle_ept_violation to unconditionally clear EPT_VIOLATION_PROT_USER_EXEC until MBEC is implemented, as suggested by Sean [1]. Note: Intel SDM Table 29-7 defines bit 6 as: If the "mode-based execute control" VM-execution control is 0, the value of this bit is undefined. If that control is 1, this bit is the logical-AND of bit 10 in the EPT paging-structure entries used to translate the guest-physical address of the access causing the EPT violation. In this case, it indicates whether the guest-physical address was executable for user-mode linear addresses. [1] https://lore.kernel.org/all/aCJDzU1p_SFNRIJd@google.com/ Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Jon Kohler <jon@nutanix.com> Message-ID: <20251223054806.1611168-2-jon@nutanix.com> Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-04-30irqchip/gic: Replace __ASSEMBLY__ with __ASSEMBLER__Thomas Huth
While the GCC and Clang compilers already define __ASSEMBLER__ automatically when compiling assembly code, __ASSEMBLY__ is a macro that only gets defined by the Makefiles in the kernel. This can be very confusing when switching between userspace and kernelspace coding, or when dealing with uapi headers that rather should use __ASSEMBLER__ instead. Standardize now on the __ASSEMBLER__ macro that is provided by the compilers. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260421113012.146528-1-thuth@redhat.com
2026-04-30tty: xtensa/iss: use strnlen to improve iss_console_writeThorsten Blum
Use strnlen() to limit scanning 's' to 'count' bytes. Use the length of 's' to decide if simc_write() should be called instead of dereferencing it first and then calling strlen(). With strnlen(), iss_console_write() is further hardened against callers where 's' is not NUL-terminated. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Message-ID: <20260430090253.237654-3-thorsten.blum@linux.dev> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2026-04-30parisc: Fix build failure for 32-bit kernel with PA2.0 instruction setHelge Deller
The CONFIG_PA11 option can not be used as a reliable check if we build a 32-bit kernel which needs the 32-bit VDSO. Instead depend on CONFIG_64BIT and CONFIG_COMPAT only. Reported-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de> Tested-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de> Signed-off-by: Helge Deller <deller@gmx.de>
2026-04-29riscv: Define __riscv_copy_{,vec_}{words,bytes}_unaligned() using ↵Nathan Chancellor
SYM_TYPED_FUNC_START After commit 67bdd7b01387 ("riscv: Split out measure_cycles() for reuse") and commit c03ad15f7cf6 ("riscv: Reuse measure_cycles() in check_vector_unaligned_access()"), there are CFI failure when booting kernels with CONFIG_CFI=y: CFI failure at measure_cycles+0x38/0xe0 (target: __riscv_copy_words_unaligned+0x0/0x50; expected type: ...) CFI failure at measure_cycles+0x38/0xe0 (target: __riscv_copy_vec_words_unaligned+0x0/0x24; expected type: ...) The __riscv_copy_*_unaligned() functions are now called indirectly but they are not defined with SYM_TYPED_FUNC_START, which is required for assembly functions called indirectly from C to pass CFI checking. Switch to SYM_TYPED_FUNC_START to clear up the CFI failures. Fixes: 67bdd7b01387 ("riscv: Split out measure_cycles() for reuse") Fixes: c03ad15f7cf6 ("riscv: Reuse measure_cycles() in check_vector_unaligned_access()") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260406-measure_cycles-cfi-failure-v1-1-03e0234ae02f@kernel.org Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-29x86/microcode/intel: Refresh old_microcode defines with Nov 2025 releaseSohil Mehta
Update the minimum expected revisions of Intel microcode based on the microcode-20251111 (November 2025) release. Add an SPDX header as well as a comment to specify that the file is auto-generated. While at it, remove an extra space before the model field to match the formatting of the other fields. Signed-off-by: Sohil Mehta <sohil.mehta@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20260407014226.1169040-2-sohil.mehta@intel.com
2026-04-28parisc: drivers: switch to dynamic root deviceJohan Hovold
Driver core expects devices to be dynamically allocated and will, for example, complain loudly if a device that lacks a release function is ever freed. Use root_device_register() to allocate and register the root device instead of open coding using a static device. While at it, drop the redundant additional reference taken at init. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Helge Deller <deller@gmx.de>
2026-04-28s390/mm: Fix phys_to_folio() usage in do_secure_storage_access()Heiko Carstens
In case of a Secure-Storage-Access exception the effective aka virtual address which caused the exception is contained within the TEID. do_secure_storage_access() incorrectly uses phys_to_folio() instead of virt_to_folio() to translate the virtual address to the corresponding folio. Fix this by using virt_to_folio() instead of phys_to_folio(). Fixes: 084ea4d611a3 ("s390/mm: add (non)secure page access exceptions handlers") Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-04-28s390/debug: Reject zero-length input in debug_input_flush_fn()Vasily Gorbik
debug_input_flush_fn() always copies one byte from the userspace buffer with copy_from_user() regardless of the supplied write length. A zero-length write therefore reads one byte beyond the caller's buffer. If the stale byte happens to be '-' or a digit the debug log is silently flushed. With an unmapped buffer the call returns -EFAULT. Reject zero-length writes before copying from userspace. Cc: stable@vger.kernel.org # v5.10+ Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-04-28s390/debug: Reject zero-length input before trimming a newlinePengpeng Hou
debug_get_user_string() duplicates the userspace buffer with memdup_user_nul() and then unconditionally looks at buffer[user_len - 1] to strip a trailing newline. A zero-length write reaches this helper unchanged, so the newline trim reads before the start of the allocated buffer. Reject empty writes before accessing the last input byte. Fixes: 66a464dbc8e0 ("[PATCH] s390: debug feature changes") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Reviewed-by: Vasily Gorbik <gor@linux.ibm.com> Tested-by: Vasily Gorbik <gor@linux.ibm.com> Link: https://lore.kernel.org/r/20260417073530.96002-1-pengpeng@iscas.ac.cn Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-04-28KVM: VMX: replace vmx_spec_ctrl_restore_host with RESTORE_HOST_SPEC_CTRL_BODYPaolo Bonzini
Reuse the same assembly as SVM, just with alternatives instead of cpu_feature_enabled(X86_FEATURE_KERNEL_IBRS). Note that Intel does need an LFENCE with eIBRS, unlike AMD's AutoIBRS. However, it is not needed for X86_FEATURE_KERNEL_IBRS because there are no conditional branches between FILL_RETURN_BUFFER and ret. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-04-28KVM: VMX: switch to RESTORE_GUEST_SPEC_CTRL_BODYPaolo Bonzini
This has exactly the same expansion, so there is no change. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-04-28KVM: SVM: extract RESTORE_*_SPEC_CTRL_BODY out of svm/vmenter.SPaolo Bonzini
Pure code movement, in preparation for using these macros for VMX as well. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-04-28KVM: SVM: adopt the same VMX_RUN_* flags as VMXPaolo Bonzini
Rename VMX_RUN_* to KVM_ENTER_* (to not confuse with KVM_RUN_* that already exists) and replace SVM's spec_ctrl_intercepted with that same bitmask. Note that KVM_ENTER_SAVE_SPEC_CTRL has the opposite polarity compared to spec_ctrl_intercepted. That is, the guest value of the MSR must be saved if it writes are *not* intercepted. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-04-28KVM: SVM: pass struct vcpu_svm to msr_write_interceptedPaolo Bonzini
Remove an unnecessary difference between Intel and AMD. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-04-28KVM: SVM: prepare for making SPEC_CTRL switch common with VMXPaolo Bonzini
Remove the local labels and restrict RESTORE_*_BODY to just the restore code itself. Since the alternatives are different between VMX and SVM, having labels in the per-vendor file and jumps in another would be too confusing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-04-28KVM: VMX: more cleanups to __vmx_vcpu_runPaolo Bonzini
Slightly improve register allocation, loading vmx only once before vmlaunch/vmresume. This also makes the code slightly more similar to the one for AMD processors, in that both keep the pointer to struct vcpu_vmx or vcpu_svm in %rdi. The code for restoring the guest value of SPEC_CTRL is also the same for Intel and AMD. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-04-28KVM: VMX: remove regs argument of __vmx_vcpu_runPaolo Bonzini
Registers are reachable through vcpu_vmx, no need to pass a separate pointer to the regs[] array. No functional change intended. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-04-28arm64: tegra: Add aspm-l1-entry-delay-ns to PCIe nodesManikanta Maddireddy
Add the aspm-l1-entry-delay-ns device tree property to all PCIe Root Port and PCIe Endpoint nodes in tegra194.dtsi and tegra234.dtsi so that ASPM L1 entrance latency is configured from device tree. - Tegra194: 4000 ns (4 us) for both Root Port and Endpoint. - Tegra234: 8000 ns (8 us) for Root Port, 16000 ns (16 us) for Endpoint. Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-04-28arm64: tegra: Fix Tegra234 MGBE PTP clockJon Hunter
The Tegra MGBE PTP clock is incorrectly named as 'ptp-ref' and not 'ptp_ref' and this causing the initialisation of the PTP clock to fail. The device-tree binding doc for the device and the Tegra MGBE driver have been updated to use the correct name and so update the device-tree for Tegra234 as well. Fixes: 610cdf3186bc ("arm64: tegra: Add MGBE nodes on Tegra234") Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-04-27x86/tdx: Disable the TDX module during kexec and kdumpVishal Verma
Use the TDH.SYS.DISABLE SEAMCALL, which disables the TDX module, reclaims all memory resources assigned to TDX, and clears any partial-write induced poison, to allow kexec and kdump on platforms with the partial write errata. On TDX-capable platforms with the partial write erratum, kexec has been disabled because the new kernel could hit a machine check reading a previously poisoned memory location. Later TDX modules support TDH.SYS.DISABLE, which disables the module and reclaims all TDX memory resources, allowing the new kernel to re-initialize TDX from scratch. This operation also clears the old memory, cleaning up any poison. Add tdx_sys_disable() to tdx_shutdown(), which is called in the syscore_shutdown path for kexec. This is done just before tdx_shutdown() disables VMX on all CPUs. For kdump, call tdx_sys_disable() in the crash path before x86_virt_emergency_disable_virtualization_cpu() does VMXOFF. Since this clears any poison on TDX-managed memory, remove the X86_BUG_TDX_PW_MCE check in machine_kexec() that blocked kexec on partial write errata platforms. Co-developed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Acked-by: Kai Huang <kai.huang@intel.com> Link: https://patch.msgid.link/20260402-fuller_tdx_kexec_support-v3-4-34438d7094bf@intel.com
2026-04-27x86/virt/tdx: Add SEAMCALL wrapper for TDH.SYS.DISABLEVishal Verma
Some early TDX-capable platforms have an erratum where a partial write to TDX private memory can cause a machine check on a subsequent read. On these platforms, kexec and kdump have been disabled in these cases, because the old kernel cannot safely hand off TDX state to the new kernel. Later TDX modules support the TDH.SYS.DISABLE SEAMCALL, which provides a way to cleanly disable TDX and allow kexec to proceed. The new SEAMCALL has an enumeration bit, but that is ignored. It is expected that users will be using the latest TDX module, and the failure mode for running the missing SEAMCALL on an older module is not fatal. This can be a long running operation, and the time needed largely depends on the amount of memory that has been allocated to TDs. If all TDs have been destroyed prior to the sys_disable call, then it is fast, with only needing to override the TDX module memory. After the SEAMCALL completes, the TDX module is disabled and all memory resources allocated to TDX are freed and reset. The next kernel can then re-initialize the TDX module from scratch via the normal TDX bring-up sequence. The SEAMCALL can return two different error codes that expect a retry. - TDX_INTERRUPTED_RESUMABLE can be returned in the case of a host interrupt. However, it will not return until it makes some forward progress, so we can expect to complete even in the case of interrupt storms. - TDX_SYS_BUSY will be returned on contention with other TDH.SYS.* SEAMCALLs, however a side effect of TDH.SYS.DISABLE is that it will block other SEAMCALLs once it gets going. So this contention will be short lived. So loop infinitely on either of these error codes, until success or other error. An error is printed if the SEAMCALL fails with anything other than the error codes that cause retries, or 'synthesized' error codes produced for #GP or #UD. e.g., an old module that has been properly initialized, that doesn't implement SYS_DISABLE, returns TDX_OPERAND_INVALID. This prints: virt/tdx: TDH.SYS.DISABLE failed: 0xc000010000000000 But a system that doesn't have any TDX support at all doesn't print anything. Co-developed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Chao Gao <chao.gao@intel.com> Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Acked-by: Kai Huang <kai.huang@intel.com> Link: https://patch.msgid.link/20260402-fuller_tdx_kexec_support-v3-3-34438d7094bf@intel.com
2026-04-27x86/virt/tdx: Pull kexec cache flush logic into arch/x86Rick Edgecombe
KVM tries to take care of some required cache flushing earlier in the kexec path in order to be kind to some long standing races that can occur later in the operation. Until recently, VMXOFF was handled within KVM. Since VMX being enabled is required to make a SEAMCALL, it had the best per-cpu scoped operation to plug the flushing into. So it is kicked off from there. This early kexec cache flushing in KVM happens via a syscore shutdown callback. Now that VMX enablement control has moved to arch/x86, which has grown its own syscore shutdown callback, it no longer make sense for it to live in KVM. It fits better with the TDX enablement managing code. In addition, future changes will add a SEAMCALL that happens immediately before VMXOFF, which means the cache flush in KVM will be too late to flush the cache before the last SEAMCALL. So move it to the newly added TDX arch/x86 syscore shutdown handler. Since tdx_cpu_flush_cache_for_kexec() is no longer needed by KVM, make it static and remove the export. Since it is also not part of an operation spread across disparate components, remove the redundant comments and verbose naming. In the existing KVM based code, CPU offline also funnels through tdx_cpu_flush_cache_for_kexec(). Add an explicit WBINVD in tdx_offline_cpu() as well, even though it may be redundant with WBINVD done elsewhere during CPU offline (e.g. hlt_play_dead()). This avoids relying on fragile code ordering for cache coherency safety. [Vishal: add explicit WBINVD in tdx_offline_cpu()] Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Chao Gao <chao.gao@intel.com> Acked-by: Kai Huang <kai.huang@intel.com> Acked-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Acked-by: Sean Christopherson <seanjc@google.com> Link: https://patch.msgid.link/20260402-fuller_tdx_kexec_support-v3-2-34438d7094bf@intel.com
2026-04-27x86/tdx: Move TDX architectural error codes into <asm/shared/tdx_errno.h>Kirill A. Shutemov
Today there are two separate locations where TDX error codes are defined: arch/x86/include/asm/tdx.h arch/x86/kvm/vmx/tdx_errno.h They have some overlap that is already defined similarly. Reduce the duplication by unifying the architectural error codes at: asm/shared/tdx_errno.h ...and update the headers that contained the duplicated definitions to include the new unified header. "asm/shared" is used for sharing TDX code between the early compressed code and the normal kernel code. While the compressed code for the guest doesn't use these error code header definitions today, it does make the types of calls that return the values they define. So place the defines in "shared" location so that it can, but leave such cleanups for future changes. [Rick: enhance log] [Vishal: reduce to a simple move of architectural defines only] Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Chao Gao <chao.gao@intel.com> Acked-by: Sean Christopherson <seanjc@google.com> Link: https://patch.msgid.link/20260402-fuller_tdx_kexec_support-v3-1-34438d7094bf@intel.com
2026-04-27arm64: dts: qcom: lemans-evk-ifp-mezzanine: Enable mdss1 display PortVishnu Saini
Enable DP controllers, DPTX0 and DPTX1 alongside their corresponding PHYs of mdss1 which corresponds to eDP2 and eDP3. Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com> Signed-off-by: Mani Chandana Ballary Kuntumalla <quic_mkuntuma@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260402095003.3758176-4-quic_mkuntuma@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-27arm64: dts: qcom: lemans-ride: Enable mdss1 display PortMani Chandana Ballary Kuntumalla
This change enables DP controllers, DPTX0 and DPTX1 alongside their corresponding PHYs of mdss1 which corresponds to edp2 and edp3. Signed-off-by: Mani Chandana Ballary Kuntumalla <quic_mkuntuma@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260402095003.3758176-3-quic_mkuntuma@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-27arm64: dts: qcom: lemans: add mdss1 display device nodesMani Chandana Ballary Kuntumalla
Add devicetree changes to enable second Mobile Display Subsystem (mdss1), Display Processing Unit(DPU), Display Port(DP), Display clock controller (dispcc1) and eDP PHYs on the Qualcomm Lemans platform. Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com> Signed-off-by: Mani Chandana Ballary Kuntumalla <quic_mkuntuma@quicinc.com> Link: https://lore.kernel.org/r/20260402095003.3758176-2-quic_mkuntuma@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-27arm64: dts: qcom: sc8280xp: Add ADSP FastRPC nodePengyu Luo
Add the FastRPC node to enable offloading compute tasks to the ADSP via the FastRPC framework. Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260403120753.105869-1-mitltlatltl@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-27arm64: dts: qcom: qcs6490-rb3gen2: Enable CAN bus controllerViken Dadhaniya
Enable the MCP2518FD CAN controller on the QCS6490 RB3 Gen2 platform. The controller is connected via SPI3 and uses a 40 MHz oscillator. Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260403-can-spi-kodiak-dtsi-v1-1-4055e67dd3fc@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-20 16:24:28 +0000