summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-06-03s390/fpu: Shorten GR_NUM / VX_NUM macrosHeiko Carstens
Use the ".irp" directive to get rid of all the repeated ".ifc" usages in fpu-insn-asm.h. Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-by: Steffen Eiden <seiden@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-03s390/ap/zcrypt: Rearrange fields within AP and zcrypt structsHarald Freudenberger
Rearrange some fields within AP and zcrypt structs to reduce memory consumption and unused holes with the help of pahole analysis of the code. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Finn Callies <fcallies@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-03gpu: nova-core: Hopper/Blackwell: select FSP Chain of Trust versionJohn Hubbard
The FSP Chain of Trust handshake is versioned: Hopper speaks version 1 and Blackwell speaks version 2. Provide the version through the FSP HAL so the boot message carries the value FSP expects, and so chipsets that do not use FSP need not express a version at all. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260603-b4-blackwell-v13-5-d9f3a06939e0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-03gpu: nova-core: Hopper/Blackwell: add FSP send/receive messagingJohn Hubbard
FSP exchanges are request/response: the driver sends an MCTP/NVDM message and must match the reply against the request before acting on it. Add the synchronous send-and-wait path that validates the response transport and message headers and confirms the reply corresponds to the request that was sent. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260603-b4-blackwell-v13-4-d9f3a06939e0@nvidia.com [acourbot: make `MessageToFsp` private.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-03gpu: nova-core: add MCTP/NVDM protocol types for firmware communicationJohn Hubbard
Add the MCTP (Management Component Transport Protocol) and NVDM (NVIDIA Data Model) wire-format types used for communication between the kernel driver and GPU firmware processors. This includes typed MCTP transport headers, NVDM message headers, and NVDM message type identifiers. Both the FSP boot path and the upcoming GSP RPC message queue share this protocol layer. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260603-b4-blackwell-v13-3-d9f3a06939e0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-03gpu: nova-core: Hopper/Blackwell: add FSP message infrastructureJohn Hubbard
FSP communication uses a pair of non-circular queues in the FSP falcon's EMEM, one for messages from the driver to FSP and one for replies, with the driver polling for response data. Add the queue registers and the low-level helpers used by the higher-level FSP message layer. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260603-b4-blackwell-v13-2-d9f3a06939e0@nvidia.com [acourbot: align register fields names with OpenRM.] [acourbot: represent registers as arrays of 8 instances, as per OpenRM.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-03gpu: nova-core: Hopper/Blackwell: add FSP falcon EMEM operationsJohn Hubbard
Add external memory (EMEM) read/write operations to the GPU's FSP falcon engine. These operations use Falcon PIO (Programmed I/O) to communicate with the FSP through indirect memory access. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260603-b4-blackwell-v13-1-d9f3a06939e0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-03selftests: livepatch: set LC_ALL=C to fix locale-dependent test failureQiang Ma
When executing the command "make -C tools/testing/selftests TARGETS=livepatch run_tests", the following error message was reported. TEST: livepatch interaction with ftrace_enabled sysctl ... not ok ... livepatch: sysctlo : setting key "kernel.ftrace_enabled": Device or resource busy livepatch: sysctl: setting key "kernel.ftrace_enabled": 设备或资源忙 ... ERROR: livepatch kselftest(s) failed not ok 5 selftests: livepatch: test-ftrace.sh # exit=1 To fix it, set LC_ALL=C. Signed-off-by: Qiang Ma <maqianga@uniontech.com> Acked-by: Miroslav Benes <mbenes@suse.cz> Acked-by: Petr Mladek <pmladek@suse.com> Link: https://patch.msgid.link/20260527095929.1504032-1-maqianga@uniontech.com Signed-off-by: Petr Mladek <pmladek@suse.com>
2026-06-03KVM: riscv: Fast-path dirty logging write faultsJinyu Tang
With dirty logging enabled, guest writes often fault on an existing 4K G-stage leaf that was write-protected only for dirty tracking. The slow path still performs the full fault handling flow and takes mmu_lock for write, even though the page-table shape does not change. x86 handles the analogous case in its fast page fault path by atomically making a writable SPTE writable again when the fault is only a write-protection fault. Add the same style of fast path for RISC-V. If a write fault hits an existing 4K leaf in a writable dirty-log memslot, mark the page dirty and atomically set the PTE writable and dirty under the read side of mmu_lock. The dirty bitmap is updated before the PTE becomes writable again. The PTE D bit is also set so systems that trap on a clear D bit do not fall back to the slow path for a writable but clean PTE. Signed-off-by: Jinyu Tang <tjytimi@163.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260517153427.94889-6-tjytimi@163.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-06-03KVM: riscv: Update G-stage PTE permissions atomicallyJinyu Tang
When a fault hits an existing G-stage leaf with the same PFN, KVM only needs to update the PTE permissions. This path will be used by read-side fault handling, so it must not overwrite a concurrent PTE update. Use the cmpxchg helper when relaxing permissions on an existing leaf, following the same concurrency model used by x86 for atomic SPTE permission updates. Retry if another CPU changed the PTE first, and use cpu_relax() while spinning. Signed-off-by: Jinyu Tang <tjytimi@163.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260517153427.94889-5-tjytimi@163.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-06-03KVM: riscv: Add a G-stage PTE cmpxchg helperJinyu Tang
Permission-only G-stage PTE updates can run in parallel once they are moved to the read side of mmu_lock. Plain set_pte() is not enough for that case because another CPU may update the same PTE first. x86 handles the same class of SPTE races with cmpxchg-based updates in its fast page fault and TDP MMU paths. Add a small RISC-V helper for atomic G-stage PTE updates. The helper reports contention to the caller and flushes the target range only when the PTE value actually changes. Signed-off-by: Jinyu Tang <tjytimi@163.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260517153427.94889-4-tjytimi@163.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-06-03KVM: riscv: Use an rwlock for mmu_lockJinyu Tang
RISC-V KVM currently uses a spinlock for mmu_lock. That serializes all G-stage MMU operations, including permission-only updates that do not allocate or free page-table pages. Use KVM's rwlock form of mmu_lock, as x86 and arm64 already do. Keep the existing map, unmap and teardown paths on the write side. This prepares RISC-V for read-side handling of G-stage permission updates. Signed-off-by: Jinyu Tang <tjytimi@163.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260517153427.94889-3-tjytimi@163.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-06-03KVM: riscv: Rely on common MMU notifier lockingJinyu Tang
The common KVM invalidation paths call kvm_unmap_gfn_range() with mmu_lock already held for write. For the standard MMU notifier path, the call chain is: kvm_mmu_notifier_invalidate_range_start() kvm_handle_hva_range() kvm_unmap_gfn_range() kvm_mmu_notifier_invalidate_range_start() leaves range.lockless clear. kvm_handle_hva_range() therefore takes KVM_MMU_LOCK(kvm) before invoking the handler. The guest_memfd path has the same locking contract: __kvm_gmem_invalidate_begin() kvm_mmu_unmap_gfn_range() kvm_unmap_gfn_range() __kvm_gmem_invalidate_begin() explicitly takes KVM_MMU_LOCK(kvm) before calling kvm_mmu_unmap_gfn_range(). So remove the local trylock and make the common locking contract explicit with lockdep_assert_held_write() like x86. Signed-off-by: Jinyu Tang <tjytimi@163.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260517153427.94889-2-tjytimi@163.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-06-03KVM: selftests: Add a test for gPAT handling in L2Yosry Ahmed
When KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT is disabled, verify that KVM correctly virtualizes the host PAT MSR and the guest PAT register for nested SVM guests. With nested NPT disabled: * L1 and L2 share the same PAT * The vmcb12.g_pat is ignored With nested NPT enabled: * An invalid g_pat in vmcb12 causes VMEXIT_INVALID * RDMSR(IA32_PAT) from L2 returns the value of the guest PAT register * WRMSR(IA32_PAT) from L2 is reflected in vmcb12's g_pat on VMEXIT * RDMSR(IA32_PAT) from L1 returns the value of the host PAT MSR Verify that save/restore with the vCPU in guest mode behaves as expected in both cases, e.g. preserves both hPAT and gPAT when NPT is enabled. Originally-by: Jim Mattson <jmattson@google.com> Signed-off-by: Yosry Ahmed <yosry@kernel.org> [sean: use even fancier macro shenanigans] Link: https://patch.msgid.link/20260528231052.404737-1-seanjc@google.com [sean: avoid use of goto, print skips] Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: selftests: Add guest_memfd regression test signed offset+size bugSean Christopherson
Add a regression (and proof-of-bug) testcase to ensure KVM rejects an offset+size that would result in a negative value when computed as a signed 64-bit value. KVM had a flaw where it would allow binding a memslot to a guest_memfd instance even with a wildly out-of-range offset, if the offset and size were both positive values, but the combined offset+size was negative. Use "0x7fffffffffffffffull - page_size", i.e. "INT64_MAX - page_size", for the offset as the size of the guest_memfd file must be at least page_size (KVM requires memslots and gmem files to be host page-size aligned). I.e. "INT64_MAX - page_size + size" is guaranteed to generate an offset+size that is negative when converted to a signed 64-bit value *and* honors KVM's alignment requirements. Reviewed-by: Ackerley Tng <ackerleytng@google.com> Tested-by: Ackerley Tng <ackerleytng@google.com> Link: https://patch.msgid.link/20260602170921.1304394-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: selftests: Expand the guest_memfd test macros to allow passing the VMSean Christopherson
Expand the gmem test macros to allow passing the VM to testcases, without needing to plumb the VM into _every_ testcase, as the vast majority of testcases only need the fd and size. No functional change intended. Reviewed-by: Ackerley Tng <ackerleytng@google.com> Tested-by: Ackerley Tng <ackerleytng@google.com> Link: https://patch.msgid.link/20260602170921.1304394-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: guest_memfd: Treat memslot binding offset+size as unsigned valuesSean Christopherson
When binding a memslot to a guest_memfd file, treat the offset and size as unsigned values to fix a bug where the sum of the two can result in a false negative when checking for overflow against the size of the file. Passing unsigned values also avoids relying on somewhat obscure checks in other flows for safety, and tracks the offset and size as they are intended to be tracked, as unsigned values. On 64-bit kernels, the number of pages a memslot contains and thus the size (and offset) of its guest_memfd binding are unsigned 64-bit values. Taking the offset+size as an loff_t instead of a uoff_t inadvertently converts the unsigned value to a signed value if the offset and/or size is massive. Locally storing the offset and size as signed values is benign in and of itself (though even that is *extremely* difficult to discern), but operating on their sum is not. For the offset, KVM explicitly checks against a negative value, which might seem like a bug as KVM could incorrectly reject a legitimate binding, but that's not actually the case as KVM_CREATE_GUEST_MEMFD takes a signed value for its size, i.e. a would-be-negative offset is also greater than the maximum possible size of any guest_memfd file. Regarding the size, while KVM lacks an explicit check for a negative value, i.e. seemingly has a flawed overflow check, KVM restricts the number of pages in a single memslot to the largest positive signed 32-bit value: if (id < KVM_USER_MEM_SLOTS && (mem->memory_size >> PAGE_SHIFT) > KVM_MEM_MAX_NR_PAGES) return -EINVAL; and so that maximum "size" will ever be is 0x7fffffff000. The sum of the two is, however, problematic. While the size is restricted by KVM's memslot logic, the offset is not, i.e. the offset is completely unchecked until the "offset + size > i_size_read(inode)" check. If the offset is the (nearly) largest possible _positive_ value, then adding size to the offset can result in a signed, negative 64-bit value. When compared against the size of the file (guaranteed to be positive), the negative sum is always smaller, and KVM incorrectly allows the absurd offset. Opportunistically add missing includes in kvm_mm.h (instead of relying on its parents). Fixes: a7800aa80ea4 ("KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory") Cc: stable@vger.kernel.org Cc: Ackerley Tng <ackerleytng@google.com> Reviewed-by: Michael Roth <michael.roth@amd.com> Reviewed-by: Ackerley Tng <ackerleytng@google.com> Link: https://patch.msgid.link/20260602170921.1304394-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: x86: Remove defunct kvm_load_segment_descriptor() declaration.Sean Christopherson
Remove a dead kvm_load_segment_descriptor() declaration, no functional change intended. Reviewed-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260529222223.870923-30-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03RDMA/umem: Fix truncation for block sizes >= 4GJason Gunthorpe
When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses. Link: https://patch.msgid.link/r/1-v1-88303e9e509f+f7-ib_umem_types_jgg@nvidia.com Cc: stable@vger.kernel.org Fixes: a808273a495c ("RDMA/verbs: Add a DMA iterator to return aligned contiguous memory blocks") Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-03KVM: x86: Drop defunct vcpu_tsc_khz() declarationSean Christopherson
Remove a dead vcpu_tsc_khz() declaration. No functional change intended. Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260529222223.870923-18-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: x86: Move async #PF helpers to x86.h (as inlines)Sean Christopherson
Move kvm_pv_async_pf_enabled() and kvm_async_pf_hash_reset() to x86.h in anticipation of extracting the majority of register and MSR specific code out of x86.c. No functional change intended. Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260529222223.870923-15-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: x86: Move update_cr8_intercept() to lapic.cSean Christopherson
Move update_cr8_intercept() to lapic.c so that it's globally visible in anticipation of extracting most of the register-specific code out of x86.c and into a new compilation unit. Opportunistically prefix the helper kvm_lapic_ to make its role/scope more obvious. No functional change intended. Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260529222223.870923-14-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: x86: Harden is_64_bit_hypercall() against bugs on 32-bit kernelsSean Christopherson
Unconditionally return %false for is_64_bit_hypercall() on 32-bit kernels to guard against incorrectly setting guest_state_protected, and because in a (very) hypothetical world where 32-bit KVM supports protected guests, assuming a hypercall was made in 64-bit mode is flat out wrong. Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://patch.msgid.link/20260529222223.870923-13-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03Revert "KVM: VMX: Read 32-bit GPR values for ENCLS instructions outside of ↵Sean Christopherson
64-bit mode" Now that kvm_<reg>_read() are mode aware, i.e. are functionally equivalent to kvm_register_read(), revert aback to the less verbose versions. No functional change intended. This reverts commit 60919eccf6764c71cef31a1afeaa1a36b8e5ab85. Acked-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://patch.msgid.link/20260529222223.870923-12-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: nSVM: Use kvm_rax_read() now that it's mode-awareSean Christopherson
Now that kvm_rax_read() truncates the output value to 32 bits if the vCPU isn't in 64-bit mode, use it instead of the more verbose (and very technically slower) kvm_register_read(). Note! VMLOAD, VMSAVE, and VMRUN emulation are still technically buggy, as they can use EAX (versus RAX) in 64-bit mode via an operand size prefix. Don't bother trying to handle that case, as it would require decoding the code stream, which would open an entirely different can of worms, and in practice no sane guest would shove garbage into RAX[63:32] and then execute VMLOAD/VMSAVE/VMRUN with just EAX. No functional change intended. Cc: Yosry Ahmed <yosry@kernel.org> Reviewed-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260529222223.870923-11-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: x86: Drop non-raw kvm_<reg>_write() helpersSean Christopherson
Drop the non-raw, mode-aware kvm_<reg>_write() helpers as there is no usage in KVM, and in all likelihood there will never be usage in KVM as use of hardcoded registers in instructions is uncommon, and *modifying* hardcoded registers is practically unheard of. While there are a few instructions that modify registers in mode-aware ways, e.g. REP string and some ENCLS varieties, the odds of KVM needing to emulate such instructions (outside of the fully emulator) are vanishingly small. Drop kvm_<reg>_write() to prevent incorrect usage; _if_ a new instruction comes along that needs to modify a hardcoded register, this can be reverted. No functional change intended. Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://patch.msgid.link/20260529222223.870923-10-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: x86: Add mode-aware versions of kvm_<reg>_{read,write}() helpersSean Christopherson
Make kvm_<reg>_{read,write}() mode-aware (where the value is truncated to 32 bits if the vCPU isn't in 64-bit mode), and convert all the intentional "raw" accesses to kvm_<reg>_{read,write}_raw() versions. To avoid confusion and bikeshedding over whether or not explicit 32-bit accesses should use the "raw" or mode-aware variants, add and use "e" versions, e.g. for things like RDMSR, WRMSR, and CPUID, where the instruction uses only bits 31:0, regardless of mode. No functional change intended (all use of "e" versions is for cases where the value is already truncated due to bouncing through a u32). Cc: Binbin Wu <binbin.wu@linux.intel.com> Cc: Kai Huang <kai.huang@intel.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Link: https://patch.msgid.link/20260529222223.870923-9-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: x86: Move inlined GPR, CR, and DR helpers from x86.h to regs.hSean Christopherson
Move inlined General Purpose Register, Control Register, and Debug Register helpers from x86.h to the aptly named regs.h, to help trim down x86.h (and x86.c in the future). Move *very* select EFER functionality as well, but leave behind the bulk of EFER handling and all other MSR handling. There is more than enough MSR code to carve out msrs.{c,h} in the future. Give is_long_bit_mode() special treatment as it's more along the lines of a CR4 bit check, but just happens to be accessed through an MSR interface. And more importantly, because giving regs.h access to is_long_bit_mode() greatly simplifies dependency chains. No functional change intended. Reviewed-by: Yosry Ahmed <yosry@kernel.org> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://patch.msgid.link/20260529222223.870923-8-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: x86: Rename kvm_cache_regs.h => regs.hSean Christopherson
Rename kvm_cache_regs.h to simply regs.h, as the "cache" nomenclature is already a lie (the file deals with state/registers that aren't cached per se), and so that more code/functionality can be landed in the header without making it a truly horrible misnomer. Deliberately drop the kvm_ prefix/namespace to align with other "local" headers, and to further differentiate regs.h from the public/global arch/x86/include/asm/kvm_vcpu_regs.h, which sadly needs to stay in asm/ so that the number of registers can be referenced by kvm_vcpu_arch. No functional change intended. Reviewed-by: Yosry Ahmed <yosry@kernel.org> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://patch.msgid.link/20260529222223.870923-7-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: x86: Trace hypercall register *after* truncating values for 32-bitSean Christopherson
When tracing hypercalls, invoke the tracepoint *after* truncating the register values for 32-bit guests so as not to record unused garbage (in the extremely unlikely scenario that the guest left garbage in a register after transitioning from 64-bit mode to 32-bit mode). Fixes: 229456fc34b1 ("KVM: convert custom marker based tracing to event traces") Reviewed-by: Yosry Ahmed <yosry@kernel.org> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://patch.msgid.link/20260529222223.870923-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: VMX: Read 32-bit GPR values for ENCLS instructions outside of 64-bit modeSean Christopherson
When getting register values for ENCLS emulation, use kvm_register_read() instead of kvm_<reg>_read() so that bits 63:32 of the register are dropped if the guest is in 32-bit mode. Note, the misleading/surprising behavior of kvm_<reg>_read() being "raw" variants under the hood will be addressed once all non-benign bugs are fixed. Fixes: 70210c044b4e ("KVM: VMX: Add SGX ENCLS[ECREATE] handler to enforce CPUID restrictions") Fixes: b6f084ca5538 ("KVM: VMX: Add ENCLS[EINIT] handler to support SGX Launch Control (LC)") Acked-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://patch.msgid.link/20260529222223.870923-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: x86/xen: Don't truncate RAX when handling hypercall from protected guestSean Christopherson
Don't truncate RAX when handling a Xen hypercall for a guest with protected state, as KVM's ABI is to assume the guest is in 64-bit for such cases (the guest leaving garbage in 63:32 after a transition to 32-bit mode is far less likely than 63:32 being necessary to complete the hypercall). Fixes: b5aead0064f3 ("KVM: x86: Assume a 64-bit hypercall for guests with protected state") Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Link: https://patch.msgid.link/20260529222223.870923-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: x86/xen: Bug the VM if 32-bit KVM observes a 64-bit mode hypercallSean Christopherson
Bug the VM if 32-bit KVM attempts to handle a 64-bit hypercall, primarily so that a future change to set "input" in mode-specific code doesn't trigger a false positive warn=>error: arch/x86/kvm/xen.c:1687:6: error: variable 'input' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] 1687 | if (!longmode) { | ^~~~~~~~~ arch/x86/kvm/xen.c:1708:31: note: uninitialized use occurs here 1708 | trace_kvm_xen_hypercall(cpl, input, params[0], params[1], params[2], | ^~~~~ x86/kvm/xen.c:1687:2: note: remove the 'if' if its condition is always true 1687 | if (!longmode) { | ^~~~~~~~~~~~~~ arch/x86/kvm/xen.c:1677:11: note: initialize the variable 'input' to silence this warning 1677 | u64 input, params[6], r = -ENOSYS; | ^ 1 error generated. Note, params[] also has the same flaw, but -Wsometimes-uninitialized doesn't seem to be enforced for arrays, presumably because it's difficult to avoid false positives on specific entries. Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://patch.msgid.link/20260529222223.870923-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03KVM: SVM: Truncate INVLPGA address in compatibility modeSean Christopherson
Check for full 64-bit mode, not just long mode, when truncating the virtual address as part of INVLPGA emulation. Compatibility mode doesn't support 64-bit addressing. Note, the FIXME still applies, e.g. if the guest deliberately targeted EAX while in 64-bit via an address size override. That flaw isn't worth fixing as it would require decoding the code stream, which would open an entirely different can of worms, and in practice no sane guest would shove garbage into RAX[63:32] and execute INVLPGA. Note #2, VMSAVE, VMLOAD, and VMRUN all suffer from the same architectural flaw of not providing the full linear address in a VMCB exit information field, because, quoting the APM verbatim: the linear address is available directly from the guest rAX register (VMSAVE, VMLOAD, and VMRUN take a physical address, but their behavior with respect to rAX is otherwise identical). Fixes: bc9eff67fc35 ("KVM: SVM: Use default rAX size for INVLPGA emulation") Reviewed-by: Yosry Ahmed <yosry@kernel.org> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://patch.msgid.link/20260529222223.870923-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-03Merge tag 'samsung-soc-7.2' of ↵Linus Walleij
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into soc/arm Samsung mach/soc changes for v7.2 Remove raw GPIO number usage from S3C6410-based crag6410 board. * tag 'samsung-soc-7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: ARM: s3c: use gpio lookup table for LEDs Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-06-03ipmi: fix refcount leak in i_ipmi_request()Wentao Liang
When a caller provides a `supplied_recv` message to i_ipmi_request(), the function increments the user's `nr_msgs` reference count. If an error occurs later, the out_err cleanup path only frees the recv_msg if the function allocated it itself (i.e., !supplied_recv). In the supplied_recv case the cleanup is skipped, leaving the reference count elevated. The caller ipmi_request_supply_msgs() does not release the supplied_recv on error, so the reference is permanently leaked. Fix this by explicitly reverting the reference count operations when a supplied recv_msg with a valid user pointer is present in the error path: decrement nr_msgs and drop the user's kref. Cc: stable@vger.kernel.org Fixes: b52da4054ee0 ("ipmi: Rework user message limit handling") Signed-off-by: Wentao Liang <vulab@iscas.ac.cn> Message-ID: <20260603120634.3758747-1-vulab@iscas.ac.cn> Signed-off-by: Corey Minyard <corey@minyard.net>
2026-06-03HID: hid-lenovo-go: cancel cfg_setup work in hid_go_cfg_remove()Manish Khadka
hid_go_cfg_probe() initialises drvdata.go_cfg_setup and schedules it to run 2 ms later: INIT_DELAYED_WORK(&drvdata.go_cfg_setup, &cfg_setup); schedule_delayed_work(&drvdata.go_cfg_setup, msecs_to_jiffies(2)); cfg_setup() dereferences drvdata.hdev to issue MCU command requests. hid_go_cfg_remove() tears down sysfs and stops the HID device, but never drains the delayed work. If the device is unbound within the 2 ms scheduling delay (a probe failure rolling back via remove, or a fast rmmod after probe), the work fires after hid_destroy_device() has dropped its reference and released the underlying hdev struct, leaving cfg_setup() with a stale drvdata.hdev pointer. Mirror the sibling driver hid-lenovo-go-s.c, whose hid_gos_cfg_remove() already calls cancel_delayed_work_sync() on its analogous work, and drain go_cfg_setup at the top of hid_go_cfg_remove(). The cancel must come before guard(mutex)(&drvdata.cfg_mutex) because cfg_setup() acquires that mutex; reversing the order would deadlock. Fixes: d69ccfcbc955 ("HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver") Cc: stable@vger.kernel.org Signed-off-by: Manish Khadka <maskmemanish@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-06-03Merge tag 'stm32-dt-for-7.2-1' of ↵Linus Walleij
git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into soc/dt STM32 DT for v7.2, round 1 Highlights: ---------- - MPU: - STM32MP13: - Enable PHY SSC (Spread Spectrum) on DHCORE DHSBC board. - Add board pin documentation stm32mp135f-dk to help user. - STMP32MP15: - Protonic: - Update MECIOR0 ans MECIOR1 boards: - Define ADC channels and GPIO line definitions in board and no longer in common file. - Fix ADC sampling. - STM32MP25: - Fix SAI addresses. * tag 'stm32-dt-for-7.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32: arm64: dts: st: Fix SAI addresses on stm32mp251 ARM: dts: stm32: stm32mp15x-mecio1-io: Move expander gpio-line-names to board files ARM: dts: stm32: stm32mp15x-mecio1-io: Fix expander gpio line typo ARM: dts: stm32: stm32mp15x-mecio1-io: Move gpio-line-names to board files ARM: dts: stm32: stm32mp15x-mecio1-io: Fix GPIO names typo ARM: dts: stm32: stm32mp15x-mecio1-io: Move divergent mecio1 ADC channels to board files ARM: dts: stm32: stm32mp15x-mecio1-io: Fix ADC sampling times ARM: dts: stm32: stm32mp15x-mecio1-io: Enable internal ADC reference ARM: dts: stm32: add board pin documentation stm32mp135f-dk ARM: dts: stm32: Enable PHY SSC on DH STM32MP13xx DHCOR DHSBC board Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-06-03Merge tag 'samsung-dt64-7.2' of ↵Linus Walleij
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into soc/dt Samsung DTS ARM64 changes for v7.2 1. Exynos850: Implement proper power off to fully shutdown the board and reduce drawn current. 2. ExynosAutov920: Add UFS storage. 3. Add Peter Griffin as a co-maintainer. I have multiple subsystems to care of and limited time. Also, with joining to SoC team I figured out it is good to plan my succession. Or backup. Peter shown both time and interest in keeping Samsung Exynos code working. He already works on and maintains Google Tensor SoC, which shares a lot with Samsung Exynos processors. Considering all this, I proposed Peter to become a co-maintainer here (same for pinctrl, which went via different tree). I will still be the one handling patches for this and (probably) next cycle, but in a further timeframe the roles could reverse with me only providing acks or reviews. If this works then depending on other duties and amount of work, I might be slowly transitioning to leave Samsung SoC maintainership. * tag 'samsung-dt64-7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: MAINTAINERS: Add Peter Griffin as a co-maintainer of Samsung Exynos SoCs arm64: dts: exynos: Add EL2 virtual timer interrupt arm64: dts: exynosautov920: enable support for ufs controller arm64: dts: exynosautov920: Add syscon hsi2 node arm64: dts: exynos850: Add syscon-poweroff node Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-06-03Merge tag 'tegra-for-7.2-arm-dt' of ↵Linus Walleij
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/dt ARM: tegra: Device tree changes for v7.2-rc1 The bulk of this is various improvements for some of the older ASUS and LG devices, but there's also support for interconnects on Tegra114 to help improve memory frequency scaling. * tag 'tegra-for-7.2-arm-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: ARM: tegra: tf600t: Invert accelerometer calibration matrix ARM: tegra: tf600t: Drop backlight regulator ARM: tegra: tf600t: Configure panel ARM: tegra: transformers: Add connector node for common trees ARM: tegra: transformer: Add support for front camera ARM: tegra: grouper: Add support for front camera ARM: tegra: p880: Lower CPU thermal limit ARM: tegra: lg-x3: Set PMIC's RTC address ARM: tegra: lg-x3: Complete video device graph ARM: tegra: Configure Tegra114 power domains ARM: tegra: Add DC interconnections for Tegra114 ARM: tegra: Add EMC OPP and ICC properties to Tegra114 EMC and ACTMON device-tree nodes ARM: tegra: Add #{address,size}-cells to Chromium-based /firmware dt-bindings: memory: Document Tegra114 External Memory Controller dt-bindings: memory: Document Tegra114 Memory Controller Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-06-03Merge tag 'tegra-for-7.2-dt-bindings' of ↵Linus Walleij
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/dt dt-bindings: Changes for v7.2-rc1 This adds a compatible string for an upcoming new chip as well as changes some maintainership information. * tag 'tegra-for-7.2-dt-bindings' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: dt-bindings: tegra: pmc: Add Tegra238 compatible dt-bindings: reserved-memory: Change maintainer for BPMP SHMEM Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-06-03Merge tag 'rtw-next-2026-06-03' of https://github.com/pkshih/rtwJohannes Berg
Ping-Ke Shih says: ================== rtw-next patches for -next Pull-request includes many random fixes and new features. Major changes are listed below: rtl8xxxu: * declare supported channel width by firmware report rtw88: * validate RX descriptor to avoid malformed data causing warnings rtw89: * support USB devices RTL8922AU * add sysfs entry to show SN and UUID for specific USB devices * support to switch USB 3.0 mode for higher performance * add more fields (mainly SIG-A/SIG-B) to radiotap in monitor mode * offload packed IO to firmware to reduce IO time (for USB devices) * add debugfs to diagnose BB healthy * more preparations for RTL8922DE ================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211_hwsim: claim DBE capabilityJohannes Berg
Claim DBE capability in UHR MAC capabilities, hostapd will have to sort out the actual DBE capabilities based on the EHT capabilities. Link: https://patch.msgid.link/20260529102644.4db84674e8c2.I8731be8ea589c94ece5623e7e716cbbc03f50466@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: AP: handle DBE for clientsJohannes Berg
In AP mode, track the BSS non-DBE bandwidth and apply that to all non-DBE clients, then track OMP updates from the clients and enable/disable DBE accordingly. For now don't send a response, clients need to have a timer anyway (it's up to the driver to set the right timeout in UHR capabilities.) Link: https://patch.msgid.link/20260529102644.be84f2b055cc.I4d2c067dfe54c47621d5a872ca07a0e754d6c20f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: parse and apply UHR DBE channelJohannes Berg
When a UHR AP has DBE enabled, parse the channel and apply it to the chandef. Apply for TX only after the OMP response (or timeout) so that the AP doesn't receive frames with DBE width before the station completed transition to DBE. Link: https://patch.msgid.link/20260529102644.cb810f212128.Ife37c2673251346e84e4250b242b31f0895520ab@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: refactor link STA bandwidth updateJohannes Berg
There's similar code in two places in HT and HE, and we need to add the same again for UHR. Rename ieee80211_link_sta_rc_update_omi() to ieee80211_link_sta_update_rc_bw() and move it to sta_info.c and update existing code that can use it to do so. Link: https://patch.msgid.link/20260529102644.577c2f304d33.I09df4fce83c4e3e6deddfecbea74ffdbeedb4927@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: Update UHR MAC capabilities to D1.4Johannes Berg
There are now 8 more reserved bits in D1.4, update the code accordingly. Link: https://patch.msgid.link/20260529102644.6e27c54cfceb.Id395c07ffde286011494fc75190dc6060117436e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: Update UHR PHY capabilities to D1.4Johannes Berg
There are new capabilities in D1.4, and some reserved bits. Update the code accordingly. Link: https://patch.msgid.link/20260529102644.f146932b21e2.I12bad84157bf809fbe285b79420143b3c456d9d2@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: explain ieee80211_determine_chan_mode() parsingJohannes Berg
Looking through element parsing behaviour for multi-BSSID and multi-link, this one seemed odd. Add a comment that explains why it's written this way. Link: https://patch.msgid.link/20260529102644.25f75c4df338.I1f1f17cc0ae8e413659654d4bbaa34260ef68e2c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: mlme: allow UHR only with MLOJohannes Berg
UHR requires MLO, not just formally but also in order for the client to understand AP BSS parameter changes, since the Critical Update Counter is inside the Multi- Link Element. Require MLO for UHR connections to avoid otherwise needed complexity such as not enabling any feature that would require tracking critical updates. Link: https://patch.msgid.link/20260529102644.43817ce87042.If4562ae9c5ca83339b397d9a344b68631cb17c4a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-16 10:47:49 +0000