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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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: a7800aa80e ("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>
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: a808273a49 ("RDMA/verbs: Add a DMA iterator to return aligned contiguous memory blocks")
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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: 229456fc34 ("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>
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: 70210c044b ("KVM: VMX: Add SGX ENCLS[ECREATE] handler to enforce CPUID restrictions")
Fixes: b6f084ca55 ("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>
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: b5aead0064 ("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>
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>
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: bc9eff67fc ("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>
Remove raw GPIO number usage from S3C6410-based crag6410 board.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmocIvwQHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD14zoEACJHKri90EP4qFDAVxvszTjKuySsc6JF8Xr
N17xdXidd7fkR3ZytBzAhBqadX1uKOcPcV2mNAb6tyMxUtG/LhJ3b0KxU0u56TpY
N6Zy9Cu9tnDn0VjA/hJw7V0FYQu+DgNPZXnynWTtpzx+HXNWIPGJgOfuzDQzQqIA
NkgkJl8LVdEvScYthcuKwdX+6Se8wekTArsfsE7sQmsFLdLnQHRSyDJSDGhDRd1d
6S8k9n8hTu6FVi3pMExCqwDrgewnafpYqxpAbfDguLRXS98mXhpVld6ksGsXX5vY
m301ddUKUBm+nwgrOyKROZyNmGsNeomY9rXY5ErOfE2k+dKdjrEgvZcesZUaEm6u
UIwrIJnKSfrKZPcLDmSCd0ypXNyoOmW7nWxvr0U7jarQaOwo43YJjS0CLCnZmSmd
ZLJAw0XfLGNZtE2mt5DBxdmxYR9HSZjUHX8RcydYRdvXGLgeTwUULXtpPUx2RVXq
5o1tPJFYQY6LYbr69TpwLeQ+QBvSKwtOlOzCHhB2QWHmGTAbEq0ncOq4qxt3qDGX
yWv7Pj+kfS10dM/Dm2SG55iuFYGbtbZDuR2az8pMabyKpaUyIh6ypZBG58H7v71K
OWCd/WfZFIjSkbKA2CLHVAB2F/tuMqvsSuc32j6KtcFGy8DytVdm8QrVE30NN57D
63/vKsUx1A==
=ws72
-----END PGP SIGNATURE-----
Merge tag 'samsung-soc-7.2' of 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>
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: b52da4054e ("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>
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: d69ccfcbc9 ("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>
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.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmocJCMQHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD11V8D/9Xi4QVtgGivuu6lpggX/VCLY7TVvDUxZQG
1Ba5ggyW/TCGTUCC2k4kQKpO1J34/jBB3JCooIJV5K1rfcoClIxkrOD58ClxDeIh
Nf4lUVxyTRLL2HkFGh/ZI5a1NrCve1x+Lj2J36DAVKUGI7UciJRHqXud37grVid3
dOVNE6N5UGew1cbRCO0ej4G///+y4exKagX5oLcNRA5o9+t0/xwCTbZg60Jv3/xm
BjPLs75CwDu5+OpnKAPcjZg12AimoIlB8o95l0WU5AggkhEfNFJ6l8EgXfmv9SBr
+/1+N2Hlw6AzDDuzDpy9pDk3rvAozR0mRoYKrC/YWoJfykligMsgtmY5cHAmbPyj
IPf8lbqQnDpCr4Px9YBt378bi+7DZt2qCuBgbHkhprlLFbLN+P+48EU3ClsZrSFz
B09FfIc3eWj9+gzq2ymuYrUV+CGDkw4u7aoWLqcTXYgUPRNMkPKC0y2lLehriJMO
hW88iUf+wgtdOLxfKuIBUReEU4+G1T8b7gfRSLQpaqLPNob7j0G5Y629LQAZtHOc
vAAmloJDepAD0eA8ezLIN+XgEhlipgTnIesQ0FqRBvh2pIT67VkpQm8mBhIsLmWe
WIh7ApcZMIH3bRh6aYAZV8jJqbtZeLqEyasqoM6NZ7Y0DxGXCdC5Z/9HZ2WNYVJg
GbNn2/iXYQ==
=KSPN
-----END PGP SIGNATURE-----
Merge tag 'samsung-dt64-7.2' of 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>
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.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmobyh8ACgkQ3SOs138+
s6GyKg//SkttJ6lDJYWZoc7rSDGMsshA4Dpys+BAb1WEdKraAyVZe9pe7YGxJ3GY
gIuKYHItT3rOuDWJXcEpaHc+0IAePVvH5719KmVwE2yRuUSij9YQpDjDGTmfJXmz
GknYUIT5mxIa96ldLL5lIUtRkUc6hWlHzdpOdWfY+5f2Pysny51HNS/rQHIMgZdI
CwN69JZQ5WKZbXLeueeNK5MxJOqFYQ/dS032cnuftz+aEjwUBuTvMy58O5WU/a98
YtgPpXi0WLFPTav4Do8JONHyn8hbBOkREt4t53GKoyIfoLmiZOU6tSlFb1WAIgWT
26TdolyaOefWlGnOV4FAlY4QCM72dpW2nydMWiUDgWLKri9sxRWLEKzqrWm833D6
0BDIySgmUmvnwmOkzVcZVkhLEFg1mJMhH4J4MSwpqMpTEpnNUNLjP8nyyQRpOuWW
f/cfwPex9qDb77WNG3ExJPjREzvXxsNBKJkrJnojMzsyK3kraXsApPgYR2N07/cE
XZavX2HMmKRnoNAIEGn+C3b8qX/4F+iHKeWoAt8J8qGx4EfhUcby3r024pWHHbgp
Q7Tu0A/Lp+iYDEHRb+VjN9w2niF5Qq0oTSK0X5Altp3F83a/sIsi/V1wWV1RmHg2
4A1deqXUryxZw8vqkovl0R5FuGv45IsfIaj81viLURAabdIdtiM=
=yQew
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-7.2-arm-dt' of 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>
This adds a compatible string for an upcoming new chip as well as
changes some maintainership information.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmobx3EACgkQ3SOs138+
s6FTGRAAtVsDzbSVE3Rzc+sTg2cJZDWh8ErH6Im+HDZXpcjfGxIqQ0bqeaQ4v2s+
CePTH5cq37ih/qum+NEqz6neSxXEZJzbJifoxs/KZUGTH0YXrlhLT0p7x9eIJF+4
WqLFEYwmofOQr9lJ58qRvVTiSiFalJT8Po14fPNJ6H6jjTE7egXsI1wGNc349sK9
ZRK1+QLyv7AurpiaFypJU8hnKAW/ZyJ4iH9CX/+Rv4x1lqozBAt7Iu6voLmUMOzp
5GJUkFIa105eAYVnutHFp12PTg7RVuJRNHyvQ7Ca1racvhVIpjSjIqAaFKbWZMO9
ThfddfLYnlrUB/EXruRW6MF9G0jw0/nmRtgrJ79BRVjClEbDczFL/aAj6io1gYX0
avn+Zl/VOdUuK5QSTbRCUjEAFlQ9H05yipGXIOwHq/2uehUNRAZqoniFxLdX9xUS
9hdD04XyA3Ep031h0DGNU7PjOX4JzSw2egPzvN/NIxr5mOX5yKyMJBcoF18Zz7Nd
eLPqTBQQAvgHFWdiObyieSHPIwYB+bAgJKnonhZy878zo9by0bmnd3Kcx9iFdGDY
gEhmooifh3MukOVnCnUYnSvZuIBsKNL3j24GSExNBJB3J+igw16t816SI6vUEzIc
jXE09LEem7ET3NN7yhByFfaU0U8u9SywoQWMnCwuMU6fsYgjvXU=
=RwWK
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-7.2-dt-bindings' of 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>
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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuyEnvMdOsBl1WjpdjlvZYmhshd8FAmof2vIACgkQjlvZYmhs
hd8Zvg//dgZR/XeDKnWS0wrI8kKock83ITTClT2en+N3BKlVRJp2SkU17F1owp5s
XHHFpyc29wWOJFy2+/rYiDr4Av0kL0Mkapsguh+bqHvJYrl3nlAziriEouQjTu/E
wHe3bz0j5wbR6eEGlUQ1dR5978CoQiAz70vtSwzcrULCqGD64DROB4eFidZO41m2
gON9Ldwc1oWWUnoIk3vwe9/19G7gkBcSWB7mSHJaxn5Od0Ma37qE6pXqtJ6o/hk2
WExhtWxfloMGRncyj1Mmcydyfuoh24pxZENnGjUSx0P2ndEpf/YwPtyoYYKL99ic
2dQ6xgZzToq3ykyWxp6Hi336UNRHD88udL1TNgpQ3gXllFfBLuRd39HBXcywPRf7
lViysy7BgS2325It99yumEzTIF13x0znrA5Z9R2wXK30DPxaL3Ov3Z4PSbUDgBCR
3fky5v9GXJ6nNOUETWCvOzJ1gTKrWexxNGX5MTAm2gd84kBg8ndAPH0qcc7wFjJC
o7qHTCtGBCu5pSnxgxL3y8dTrk/WQYhMM0FjqF1ok2ddxJDtgw4FYg/MW82gh2bf
CvS36+GTJg8KF1rHPfMrEpcCFcVMlJQs1l8kfbaXMQrXvpPsvyHjSr3RSKfxEalD
GNiOGWRi0MhL1V9An9JHr5tbWGfCAcEp0DMv/ykvLTQiYwogLWc=
=7iaf
-----END PGP SIGNATURE-----
Merge tag 'rtw-next-2026-06-03' of https://github.com/pkshih/rtw
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>
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>
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>
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>
During beacon processing, the parser is always called with
a BSS to find the correct multi-BSSID profile (if any) and
therefore never attempts to parse a multi-link element.
This means the code to handle cross-link CSA can effectively
never do anything.
Fix this by parsing the multi-link element in the regular
parser as well.
Fixes: 7ef8f6821d ("wifi: mac80211: mlme: handle cross-link CSA")
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Benjamin Berg <benjamin.berg@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20260529102644.2a74b2659f50.I8f9454bf5e05c419a9b1eb23ecad302a6bf63fbb@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
