summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2026-07-10KVM: x86: Reject nested CAP enablement if nested virtualization is disabledSean Christopherson
Add a flag to explicitly track if nested virtualization is enabled, and use it enumerate that various nested CAPs are unsupported, and to reject enablement of said CAPs. When the nested ops hooks were moved to their own structure, KVM's NULL-by-default behavior was deliberately dropped, with the changelog asserting that all was well. That wasn't quite true; there is no danger to KVM, but now KVM is over-reporting support for KVM_CAP_NESTED_STATE and KVM_CAP_HYPERV_ENLIGHTENED_VMCS. Fixes: 33b22172452f ("KVM: x86: move nested-related kvm_x86_ops to a separate struct") Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Link: https://patch.msgid.link/20260630202828.440724-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-10KVM: TDX: Reject concurrent change to CPUID entry countBinbin Wu
Reject KVM_TDX_INIT_VM if userspace changes cpuid.nent between the initial read and the subsequent copy of the initialization data. tdx_td_init() first reads user_data->cpuid.nent to size the flexible kvm_tdx_init_vm copy. The copied structure also contains cpuid.nent, and that field can differ from the value used to size the allocation if userspace modifies the input concurrently. setup_tdparams_cpuids() later passes init_vm->cpuid.nent to kvm_find_cpuid_entry2(), which uses it as the array bound for the copied entries. Require the copied count to match the value used to size the allocation so that CPUID parsing cannot access beyond the entries actually copied. Fixes: 0bd0a4a1428b ("KVM: TDX: Replace kmalloc + copy_from_user with memdup_user in tdx_td_init()") Reported-by: Sashiko:gemini-3.1-pro-preview Cc: <stable@vger.kernel.org> Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20260710035324.3170534-1-binbin.wu@linux.intel.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-10ARM: dts: st: spear13xx: Drop unused/incorrect usbh0_id and usbh1_idKrzysztof Kozlowski
"usbh0_id" and "usbh1_id" properties were never documented and never used by Linux drivers, thus should be safe to drop to fix dtbs_check warnings like: st/spear1310-evb.dtb: usb@e4800000 (st,spear600-ehci): Unevaluated properties are not allowed ('usbh0_id' was unexpected) st/spear1310-evb.dtb: usb@e5800000 (st,spear600-ehci): Unevaluated properties are not allowed ('usbh1_id' was unexpected) Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/20260625091355.107054-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-07-10KVM: x86: Guard .gmem_prepare() declarations with HAVE_KVM_GMEM_PREPARE=ySean Christopherson
Wrap the .gmem_prepare() declarations with HAVE_KVM_GMEM_PREPARE so that non-SEV code doesn't try to wire up a callback without doing the necessary enabling. No functional change intended. Fixes: 3bb2531e20bf ("KVM: guest_memfd: Add hook for initializing memory") Reviewed-by: Ackerley Tng <ackerleytng@google.com> Reviewed-by: Michael Roth <michael.roth@amd.com> Link: https://patch.msgid.link/20260709204948.1988414-13-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-10KVM: SEV: Mark vCPU has having guest-provided VMSA even if its invalidSean Christopherson
Track the guest as having a guest-provided VMSA as soon as control.vmsa_pa is invalidated, instead of waiting to see if the guest-provided VMSA is usable, so that KVM doesn't switch back to the original VMSA instead of exiting to userspace (due to an invalid VMSA). By the time a vCPU tries to load a guest-provided VMSA, KVM has already communicated "success" for AP creation, i.e. KVM has committed to using the guest-provided VMSA. Reviewed-by: Michael Roth <michael.roth@amd.com> Link: https://patch.msgid.link/20260709204948.1988414-12-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-10KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zappedSean Christopherson
Wire up a gmem_invalidate_range() call for SNP VMs, and use it to force vCPUs to reload/recheck their guest-provided VMSA if the backing gmem page is being invalidated, e.g. is being PUNCH_HOLE'd. Use the same core logic to handle invalidations as VMX does for the APIC-access page, as the two concepts are nearly identical: shove the physical address of a page into the vCPU's control structure: 1. Snapshot the invalidation sequence counter 2. Grab the pfn (from guest_memfd in this case) 3. Acquire mmu_lock for read 4. Re-request reload if retry is needed, otherwise commit the change. Note, the re-request action in #4 is necessary as KVM's retry logic is fuzzy, i.e. can get false positives. If the guest_memfd page has been dropped, at some point a subsequent reload will fail to get a PFN from guest_memfd, and KVM will fail KVM_RUN. If the retry was due to a false positive, KVM will retry until there are no relevant MMU notifier events (and will retry in the "outer" loop, i.e. will drop locks and resched as needed). Note #2! Take care to invalidate the VMSA when a relevant memslot is DELETED or MOVED, as invalidations in response to PUNCH_HOLE are predicated on memslot bindings (KVM doesn't know what GFN range(s) to invalidate without a binding). And more importantly, the VMSA mapping requires a memslot, i.e. must be invalidated if its memslots disappears, regardless of the state of the underlying guest_memfd inode. Failure to invalidate the vCPU's control.vmsa_pa (which is checked by pre_sev_run()) can prevent KVM from properly freeing the page as firmware will reject the RMPUPDATE to reclaim the page with FAIL_INUSE if the vCPU is actively running, i.e. if VMSA page is in-use. That in turn leads to an RMP #PF on the next use, as the page will still be assigned to the SNP VM. SEV-SNP: RMPUPDATE failed for PFN 78d198, pg_level: 1, ret: 3 SEV-SNP: PFN 0x78d198, RMP entry: [0xfff0000000144001 - 0x000000000000000f] CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 Call Trace: <TASK> dump_stack_lvl+0x54/0x70 rmpupdate+0x12c/0x140 rmp_make_shared+0x3b/0x60 sev_gmem_invalidate+0xe0/0x170 [kvm_amd] delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e </TASK> ------------[ cut here ]------------ SEV: Failed to update RMP entry for PFN 0x78d198 error -14 WARNING: arch/x86/kvm/svm/sev.c:5160 at sev_gmem_invalidate+0x126/0x170 [kvm_amd], CPU#3: sev_snp_vmsa_pu/31345 CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 RIP: 0010:sev_gmem_invalidate+0x12b/0x170 [kvm_amd] Call Trace: <TASK> delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e </TASK> irq event stamp: 20689 hardirqs last enabled at (20699): [<ffffffff8e76092c>] __console_unlock+0x5c/0x60 hardirqs last disabled at (20708): [<ffffffff8e760911>] __console_unlock+0x41/0x60 softirqs last enabled at (20722): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140 softirqs last disabled at (20717): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140 ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: ffff99a64d198000 #PF: supervisor write access in kernel mode #PF: error_code(0x80000003) - RMP violation PGD 13eb001067 P4D 13eb001067 PUD 78d1d1063 PMD 1184e0063 PTE 800000078d198163 SEV-SNP: PFN 0x78d198, RMP entry: [0x6030000000144001 - 0x000000000000000f] Oops: Oops: 0003 [#1] SMP CPU: 3 UID: 0 PID: 31407 Comm: highlanderd_hea Tainted: G U W O Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 RIP: 0010:prep_new_page+0x67/0x220 Call Trace: <TASK> get_page_from_freelist+0x1c40/0x1c70 __alloc_frozen_pages_noprof+0xca/0x1f0 alloc_pages_mpol+0x10b/0x1b0 alloc_pages_noprof+0x81/0x90 pte_alloc_one+0x1b/0xd0 do_pte_missing+0xdf/0x1020 handle_mm_fault+0x7c7/0xb20 do_user_addr_fault+0x268/0x6b0 exc_page_fault+0x67/0xa0 asm_exc_page_fault+0x26/0x30 RIP: 0033:0x4a6b1e </TASK> gsmi: Log Shutdown Reason 0x03 CR2: ffff99a64d198000 ---[ end trace 0000000000000000 ]--- RIP: 0010:prep_new_page+0x67/0x220 Drop the pseudo-TODO comment about needing to pin the page if guest_memfd every supports migration, as integrating with invalidations events means KVM will Just Work if/when page migration is ever supported (assuming SNP hardware supports migrating VMSA pages). Note #3, invalidate() and invalidate_range() have _completely_ different semantics; the new invalidate_range() is a true invalidation, whereas the existing invalidate() is really a "make shared" operation. Ignore the confusing naming and poor Kconfig bundling for the moment to minimize the delta for LTS kernels, the mess will be cleaned up shortly. Reported-by: Hyunwoo Kim <imv4bel@gmail.com> Closes: https://lore.kernel.org/all/aimMWzAf5b3luM0b@v4bel Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event") Cc: stable@vger.kernel.org Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Jörg Rödel <joro@8bytes.org> Cc: Fuad Tabba <tabba@google.com> Cc: Ackerley Tng <ackerleytng@google.com> Reviewed-by: Michael Roth <michael.roth@amd.com> Link: https://patch.msgid.link/20260709204948.1988414-11-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-10KVM: x86/mmu: Use split "zap all fast" helpers when invalidating memslotSean Christopherson
Manually invoke the front half and back half of the "zap all fast" flow when invalidating a memslot so that mmu_lock is acquired at function scope in kvm_arch_flush_shadow_memslot(). This will allow putting more code inside the critical section without having to take mmu_lock twice in quick succession. Opportunistically open code checking whether or not to do the fast zap, to discourage removing the local "zap_all" in a future cleanup, i.e. to ensure the SLOT_ZAP_ALL quirk is queried exactly once. Processing the front half but not the back half of the fast zap (if SLOT_ZAP_ALL were disabled concurrently) would result in KVM unnecessarily keeping invalid TDP MMU roots until the VM is destroyed. No functional change intended. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth <michael.roth@amd.com> Link: https://patch.msgid.link/20260709204948.1988414-10-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-10KVM: x86/mmu: Split kvm_mmu_zap_all_fast() into "front" and "back" halvesSean Christopherson
Split kvm_mmu_zap_all_fast() into a "front half" and a "back half", where the front half is everything that runs with mmu_lock held for write, and the back half is the code that runs outside of mmu_lock. This will allow putting more code inside kvm_arch_flush_shadow_memslot()'s critical section without having to take mmu_lock twice in quick succession. No functional change intended. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth <michael.roth@amd.com> Link: https://patch.msgid.link/20260709204948.1988414-9-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-10KVM: x86/mmu: Fold kvm_mmu_zap_memslot() into kvm_arch_flush_shadow_memslot()Sean Christopherson
Fold kvm_mmu_zap_memslot() into its sole caller so that its GFN range structure can be used to trigger guest_memfd invalidations regardless of whether KVM will do a partial or full zap of the MMU. No functional change intended. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth <michael.roth@amd.com> Link: https://patch.msgid.link/20260709204948.1988414-8-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-10KVM: x86: Ensure runtime reads of disabled_quirks are resolved onceSean Christopherson
Wrap the sole reader of disabled_quirks with READ_ONCE(), and wrap the post-VM-creation write to disabled_quirks with WRITE_ONCE(), to ensure checking the status of a quirk doesn't re-read disabled_quirks *if* the caller needs such a guarantee. This will allow splitting the "fast" MMU zap into front and back halves, without potentially skipping the back half if SLOT_ZAP_ALL were concurrently disabled (which would be "fine" in the current code base, but far from ideal). Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth <michael.roth@amd.com> Link: https://patch.msgid.link/20260709204948.1988414-7-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-10KVM: x86: Serialize writes to disabled_quirks using kvm->lockSean Christopherson
Protect writes to disabled_quirks with kvm->lock to ensure KVM doesn't clobber state in the unlikely scenario that userspace disables disparate quirks from multiple tasks. More importantly, this will allow wrapping accesses with {READ,WRITE}_ONCE without "needing" to also guard the writer with a useless and confusing READ_ONCE (since the RMW wouldn't be atomic anyways). Ideally, KVM would disallow disabling quirks once quirks are "live", but that would be a potentially breaking userspace ABI change, and while all existing quirks are fully live only after vCPUs have been created, several MMU-related quirks, IGNORE_GUEST_PAT and SLOT_ZAP_ALL, are partially live at all times. Because populating MMUs requires a vCPU, the guest-visible behavior of IGNORE_GUEST_PAT and SLOT_ZAP_ALL requires a vCPU, but for KVM itself, processing the quirk (or not) has functional impact, i.e. for all intents and purposes, KVM can't prevent those quirks from being disabled after they've been consumed. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth <michael.roth@amd.com> Link: https://patch.msgid.link/20260709204948.1988414-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-10KVM: SEV: Wire up kvm_x86_ops.gmem_xxx() if and only if CONFIG_KVM_AMD_SEV=ySean Christopherson
Wire up the SEV-SNP guest_memfd kvm_x86_ops hooks if and only if SEV is actually enabled, and drop the now-unnecessary stubs. Leaving the hooks NULL allows the static call infrastructure to elide the CALL+RET, and more importantly, referencing the hooks if and only if SEV support is enabled will allow conditionally definining the hooks using their corresponding HAVE_KVM_ARCH_GMEM_XXX Kconfig. No functional change intended. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Ackerley Tng <ackerleytng@google.com> Link: https://patch.msgid.link/20260709204948.1988414-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-10KVM: SEV: Mark vCPU RUNNABLE after AP_CREATE, even if VMSA is unusableSean Christopherson
Always mark the vCPU as RUNNABLE after responding to AP_CREATE, even if the guest-specified VMSA is unusable, e.g. isn't backed by a memslot or doesn't have a backing guest_memfd page. If the VMSA is unusable, leaving the vCPU in a non-running state will effectively hang the vCPU instead of reporting an error to userspace. This will also allow retrying the VMSA load in the future, to fix a bug where KVM doesn't honor guest_memfd invalidation events, e.g. if AP_CREATION races with PUNCH_HOLE. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth <michael.roth@amd.com> Link: https://patch.msgid.link/20260709204948.1988414-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-10KVM: SEV: Extract loading of guest-provided VMSA to a separate helperSean Christopherson
Extract the loading/retrieval of a guest-provided VMSA to a separate helper so that KVM can reuse the core logic when refreshing the VMSA after an MMU invalidation from guest_memfd. No functional change intended. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth <michael.roth@amd.com> Link: https://patch.msgid.link/20260709204948.1988414-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-10KVM: SEV: Track the GPA of the guest-controlled VMSA used for SNP guestsSean Christopherson
Track the GPA of the guest-provided VMSA used after AP_CREATION events when running SNP guests, instead of simply tracking whether or not the vCPU is using a guest-provided VMSA. KVM needs to know the GPA of the VMSA that's actively being used so that it can react to MMU invalidation events, i.e. so that KVM can drop the VMSA if its backing guest_memfd page is punched out of existence. Opportunistically rename snp_vmsa_gpa to clarify that it tracks the pending VMSA GPA, whereas snp_guest_vmsa_gpa now tracks the in-use VMSA GPA. Note! Take care to track the GPA, not the GFN, as VALID_PAGE() won't behave correctly if an invalid GFN is converted to a GPA for checking. Note #2! Keep snp_has_guest_vmsa so that switching to a guest-provided VMSA is sticky, even if the guest-provided VMSA becomes invalid. No functional change intended. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth <michael.roth@amd.com> Link: https://patch.msgid.link/20260709204948.1988414-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-10KVM: SEV: Do not allow intra-host migration/mirroring of SNP VMsAtish Patra
The intra-host migration/mirroring feature is not fully implemented for SEV-SNP VMs. The proper migration requires additional SNP-specific state such as guest_req_mutex, guest_req_buf, and guest_resp_buf to be transferred or initialized on the destination. The SNP VM mirroring requires vmsa features to be copied as well otherwise ASID would be bound to SNP range while VM is detected as a SEV VM. Reject SNP source VMs in migration/mirroring until proper SNP state transfer is implemented. Fixes: 1dfe571c12cf ("KVM: SEV: Add initial SEV-SNP support") Reported-by: Chris Mason <clm@meta.com> Reported-by: Sashiko <sashiko-bot@kernel.org> Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Atish Patra <atishp@meta.com> Link: https://patch.msgid.link/20260602-sev_snp_fixes-v3-1-24bfd3ae047c@meta.com Cc: stable@vger.kernel.org [sean: let lines poke past 80 chars, tag for stable] Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-10KVM: SVM: Remove redundant ret = 0 in svm_set_nested_stateQiang Ma
In svm_set_nested_state(), the success path reaches out_free with ret already set to 0 from nested_svm_load_cr3(). The explicit 'ret = 0' assignment before out_free is therefore redundant. Remove it. No functional change. Signed-off-by: Qiang Ma <maqianga@uniontech.com> Link: https://patch.msgid.link/20260618085217.3934985-1-maqianga@uniontech.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-10powerpc/powermac: use platform_device_set_of_node()Bartosz Golaszewski
Ahead of reworking the reference counting logic for platform devices, encapsulate the assignment of the OF node for dynamically allocated platform devices with the provided helper. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260706-pdev-fwnode-ref-v3-7-1ff028e33779@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-10powerpc/powermac: fix OF node refcountBartosz Golaszewski
Platform devices created with platform_device_alloc() call platform_device_release() when the last reference to the device's kobject is dropped. This function calls of_node_put() unconditionally. This works fine for devices created with platform_device_register_full() but users of the split approach (platform_device_alloc() + platform_device_add()) must bump the reference of the of_node they assign manually. Add the missing call to of_node_get(). Cc: stable@vger.kernel.org Fixes: 81e5d8646ff6 ("i2c/powermac: Register i2c devices from device-tree") Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260706-pdev-fwnode-ref-v3-1-1ff028e33779@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-10perf/x86/amd/lbr: Fix kernel address leakageSandipan Das
A user-only branch stack can contain branches that originate from the kernel. As a result, kernel addresses are exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. On AMD processors supporting X86_FEATURE_AMD_LBR_V2, perf can still report SYSRET/ERET entries for which the branch-from addresses are in the kernel. E.g. $ perf record -e cycles -o - -j any,save_type,u -- \ perf bench syscall basic --loop 1000 | \ perf script -i - -F brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' ... 0xffffffff81001268/0x717a90a38f1a/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a39157/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a2c628/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a41b60/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a8bef1c30/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a8e4d3c90/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH ... The reason is that the hardware filter only considers the privilege level applicable to the branch target. Extend software filtering to also validate the branch-from addresses against br_sel, so that any branch record whose branch-from address is in the kernel is dropped when PERF_SAMPLE_BRANCH_USER is requested. Fixes: f4f925dae741 ("perf/x86/amd/lbr: Add LbrExtV2 hardware branch filter support") Reported-by: Ian Rogers <irogers@google.com> Signed-off-by: Sandipan Das <sandipan.das@amd.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: stable@vger.kernel.org Cc: Peter Zijlstra <peterz@infradead.org> Link: https://patch.msgid.link/a898a29725f6b2f30518354cdc2e432db66c43cf.1783680119.git.sandipan.das@amd.com
2026-07-10ARM: dts: st: ste: Correct indentationKrzysztof Kozlowski
Correct spaces or mix of tabs+spaces into proper tab-indented lines. No functional impact (same DTB). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260706101823.341230-4-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-07-10ARM: dts: st: spear: Correct indentationKrzysztof Kozlowski
Correct spaces or mix of tabs+spaces into proper tab-indented lines. No functional impact (same DTB). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/20260706101823.341230-3-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-07-10ARM: Don't let ARMv5 platforms select USE_OFUwe Kleine-König (The Capable Hub)
USE_OF is already selected by ARM (unless ARCH_FOOTBRIDGE || ARCH_RPC || ARCH_SA1100; these all conflict with ARCH_MULTI_V5). So there is no need for an explicit select and it can be dropped. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20260705085000.3510576-2-u.kleine-koenig@baylibre.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-07-10Merge tag 'tegra-for-7.2-arm64-dt-fixes' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/fixes arm64: tegra: Device tree fixes for v7.2 These changes fix an invalid compatible string combination for GPC DMA on Tegra264, change the compatible string for the CPU found on Tegra234 and update the unit-address of CPU#1 on Tegra264 so it matches the value in the "reg" property. * tag 'tegra-for-7.2-arm64-dt-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: arm64: tegra: Fix CPU1 node unit-address on Tegra264 arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234 arm64: tegra: Remove fallback compatible for GPCDMA Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-07-10powerpc/pseries/Kconfig: Enable CONFIG_VPA_PMU to be used with KVMGautam Menghani
Currently, CONFIG_VPA_PMU is not enabled by default, and consequently cannot be used for KVM guests at all, unless explicitly enabled on host kernel. Mark CONFIG_VPA_PMU as "default m" to ensure it is available when KVM is being used. Cc: stable@vger.kernel.org # v6.13+ Suggested-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Amit Machhiwal <amachhiw@linux.ibm.com> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Signed-off-by: Gautam Menghani <gautam@linux.ibm.com> [Maddy: Changed tag order] Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260615091120.84169-1-gautam@linux.ibm.com
2026-07-10x86/thermal: Add bit definitions for Intel Directed Package Thermal InterruptRicardo Neri
Add CPUID and MSR bit definitions required to support Intel Directed Package Thermal Interrupt. A CPU requests directed package-level thermal interrupts by setting bit 25 in IA32_THERM_INTERRUPT. Hardware acknowledges by setting bit 25 in IA32_PACKAGE_THERM_STATUS, indicating that only CPUs that opted in will receive the interrupt. If no CPU in the package requests it, delivery falls back to broadcast. Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Link: https://patch.msgid.link/20260613-rneri-directed-therm-intr-v3-2-3a26d1e47fc8@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-10x86/boot/compressed/head_64.S: Clean up SEV-related commentsBorislav Petkov (AMD)
Move the comment about setting the encryption mask above the line which does that and, especially, inside the ifdeffery, where it belongs. Move comments on top of the code lines they refer to and not on the side, which impairs readability. No functional changes. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://patch.msgid.link/20260620043757.347076-1-bp@kernel.org
2026-07-10x86/build: Only align ENTRY_TEXT to PMD_SIZE if necessaryHamza Mahfooz
PTI requires the begin and end of ENTRY_TEXT be aligned to PMD_SIZE. SRSO requires srso_alias_untrain_ret to be 2M aligned. This costs between 2-4 MiB of RAM (depending on the size of the preceding section). So, only align when either of the two are enabled. Co-developed-by: Jared White <jaredwhite@microsoft.com> Signed-off-by: Jared White <jaredwhite@microsoft.com> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://patch.msgid.link/20260623152430.1473481-1-hamzamahfooz@linux.microsoft.com
2026-07-10Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netPaolo Abeni
Cross-merge networking fixes after downstream PR (net-7.2-rc3). Conflicts: tools/testing/selftests/net/lib.sh dd6a23bac306b ("selftests: net: make busywait timeout clock portable") 895bad9cc4cec ("selftests: net: make busywait timeout clock portable") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-09m68k: avoid -Wunused-but-set-parameter in clear_user_page()Thomas Weißschuh
The loop in clear_user_pages() iterates over all pages and calls clear_user_page() for each of them. During the loop "vaddr" is modified. However on m68k clear_user() is a macro which does not use "vaddr". The compiler sees a variable which is modified but never used and emits a warning for that: include/linux/highmem.h: In function 'clear_user_pages': include/linux/highmem.h:234:63: warning: parameter 'vaddr' set but not used [-Wunused-but-set-parameter=] static inline void clear_user_pages(void *addr, unsigned long vaddr, Other architectures use an inline function for clear_user_page() which avoids the warning. This is not possible on m68k, as dlush_dcache_page() is another macro which is not yet defined where clear_user_page() is defined. Including cacheflush_mm.h will trigger recursive and lots of other issues. So hide the warning with a cast to (void) instead. While we are here, do the same for copy_user_page(). Link: https://lore.kernel.org/20260525-m68k-clear_user_page-v2-1-0c8981c6eca1@weissschuh.net Fixes: 62a9f5a85b98 ("mm: introduce clear_pages() and clear_user_pages()") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Andreas Schwab <schwab@linux-m68k.org> Cc: Ankur Arora <ankur.a.arora@oracle.com> Cc: David Hildenbrand <david@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-09KVM: s390: pci: Fix handling of AIF enable without AISBMatthew Rosato
When a guest seeks to register IRQs without a summary bit specified, ensure that the associated GAITE then stores 0 for the guest AISB location instead of virt_to_phys(page_address(NULL)). Fixes: 3c5a1b6f0a18 ("KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding") Cc: stable@vger.kernel.org Reviewed-by: Farhan Ali <alifm@linux.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
2026-07-09x86/platform/olpc: xo15: Stop setting acpi_device_name/class()Rafael J. Wysocki
The driver sets acpi_device_name() and acpi_device_class() which are never read afterward, so make it stop doing that and drop the symbols defined specifically for this purpose. No intentional functional impact. This will facilitate the removal of device_name and device_class from struct acpi_device_pnp in the future. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/2866696.mvXUDI8C0e@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-07-09ACPI: irq: Move RISC-V interrupt controllers autodep to ACPI IRQ codeLorenzo Pieralisi
RISC-V implements arch code to detect probe dependencies for devices and the interrupt controller the devices GSIs are routed to. The code itself is arch agnostic apart from an arch specific helper function required to retrieve the acpi_handle of the interrupt controller that manages the device GSI interrupt. In order to enable IRQ probe dependencies detection on other architectures, move RISC-V IRQ probe dependency detection code to generic ACPI IRQ code. Allow interrupt controller drivers to register an arch specific function to determine the acpi_handle for a specific GSI number to use the mechanism if needed by the respective interrupt controller drivers. Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com> Tested-by: Sunil V L <sunilvl@oss.qualcomm.com> Link: https://patch.msgid.link/20260709-gic-v5-acpi-iwb-probe-deferral-v4-5-48dae790f871@kernel.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-09arm64: dts: mediatek: mt8195: Add and use UART AP_DMA controllerAngeloGioacchino Del Regno
This SoC has a DMA controller (AP_DMA) that provides one channel for each data direction (transmit and receive) for all of the UART controllers in the SoC. In order to increase the efficiency of data TX/RX over the UART controllers, add the UART DMA controller and assign the right channels to each uart controller. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-07-09arm64: dts: mediatek: mt8192: Add and use UART AP_DMA controllerAngeloGioacchino Del Regno
This SoC has a DMA controller (AP_DMA) that provides one channel for each data direction (transmit and receive) for all of the UART controllers in the SoC. In order to increase the efficiency of data TX/RX over the UART controllers, add the UART DMA controller and assign the right channels to its two uart controllers. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-07-09arm64: dts: mediatek: mt8188: Add and use UART AP_DMA controllerAngeloGioacchino Del Regno
This SoC has a DMA controller (AP_DMA) that provides one channel for each data direction (transmit and receive) for all of the UART controllers in the SoC. In order to increase the efficiency of data TX/RX over the UART controllers, add the UART DMA controller and assign the right channels to each of the four UART controllers that are declared. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-07-09arm64: dts: mediatek: mt8186: Add and use UART AP_DMA controllerAngeloGioacchino Del Regno
This SoC has a DMA controller (AP_DMA) that provides one channel for each data direction (transmit and receive) for all of the UART controllers in the SoC. In order to increase the efficiency of data TX/RX over the UART controllers, add the UART DMA controller and assign the right channels to each of the three UART controllers. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-07-09arm64: dts: mediatek: mt8183: Add and use UART AP_DMA controllerAngeloGioacchino Del Regno
This SoC has a DMA controller (AP_DMA) that provides one channel for each data direction (transmit and receive) for all of the UART controllers in the SoC. In order to increase the efficiency of data TX/RX over the UART controllers, add the UART DMA controller and assign the right channels to each of the three UART controllers. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-07-09arm64: dts: mediatek: mt6795: Remove deprecated UART DMA propertyAngeloGioacchino Del Regno
Remove the mediatek,dma-33bits property as it is now deprecated and, while at it, also remove the fallback compatible as it was not entirely right to use anyway, because this IP is not fully compatible with the one found in MT6577 and would create more issues than the ones it could resolve (as in - it's better to not probe the controller than to probe it and manage it in some incorrect way). Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-07-09arm64: dts: mediatek: tungsten-smarc: Remove unnecessary cellsAngeloGioacchino Del Regno
Remove unnecessary address and size cells from both the disp_dsi0 and the xhci2's ethernet usb device subnode to fix a dtbs_check warning for avoid_unnecessary_addr_size. Fixes: 9fda4a8a479f ("arm64: dts: mediatek: add device tree for Tungsten 510 board") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-07-09KVM: s390: Improve kvm_s390_vm_stop_migration()Claudio Imbrenda
There is no need to clear cmma-dirty state if the VM is not using CMMA. Skip the CMMA-related code if CMMA is not in use. Fixes: 6cfd47f91f6a ("KVM: s390: Fix cmma dirty tracking") Fixes: 190df4a212a7 ("KVM: s390: CMMA tracking, ESSA emulation, migration mode") Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
2026-07-09KVM: s390: Fix dat_crste_walk_range() early returnClaudio Imbrenda
If a walk entry handler for a lower level returns a value, dat_crste_walk_range() will not return immediately, but instead loop again and move to the next entry. This means that some entries are potentially skipped, and early return is ignored. Skipped entries might lead to all kinds of issues, given that the caller expects them to not be skipped. Early return is often used to interrupt a walk when a rescheduling is needed; if it is ignored it can lead to stalls. Fix by breaking from the loop immediately if the walk to a lower level returned non-zero. Fixes: 2db149a0a6c5 ("KVM: s390: KVM page table management functions: walks") Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
2026-07-09KVM: s390: vsie: Avoid potential deadlock with real spacesClaudio Imbrenda
The natural lock ordering is mmu_lock -> children_lock, but in gmap_create_shadow() the reverse order is used when handling shadowing of real address spaces. Convert the inner locking of kvm->mmu_lock to a trylock; return -EAGAIN if the lock is busy, and let the caller try again. This path is not expected to happen in real-life scenarios, so its performance is not important. Fixes: a2c17f9270cc ("KVM: s390: New gmap code") Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
2026-07-09KVM: s390: pci: Fix GISC refcount leak on AIF enable failureHaoxiang Li
kvm_s390_gisc_register() registers the guest ISC before pinning the guest interrupt forwarding pages and allocating the AISB bit. If any of the later setup steps fails, the function unwinds the pinned pages and other local state, but does not unregister the GISC reference. Add the missing kvm_s390_gisc_unregister() to the error unwind path. Fixes: 3c5a1b6f0a18 ("KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Tested-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260624061910.2794734-1-haoxiang_li2024@163.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
2026-07-08KVM: VMX: Use cached vcpu_vmx pointer in MSR and segment helpersHao Zhang
vmx_get_msr() and vmx_set_msr() already cache to_vmx(vcpu) in a local 'vmx' pointer, but a few cases still open-code to_vmx(vcpu). Use the cached pointer for consistency. Likewise, cache to_vmx(vcpu) in vmx_get_segment_base() instead of open-coding it in both the real-mode check and the VMCS read path. No functional change intended. Signed-off-by: Hao Zhang <zhanghao1@kylinos.cn> Link: https://patch.msgid.link/tencent_A78DC401911634111A3391650CB00FCD0409@qq.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-08KVM: SVM: Remove VM from the GA Log notifier list before VM destructionSean Christopherson
When a VM is being destroyed, delete it from the list used to process GA Log interrupts before vCPUs are freed, otherwise avic_ga_log_notifier() could theoretically hit a use-after-free if a GA Log notification arrives for a vCPU after the last reference to the VM has been put. Note, in practice, it's likely all but impossible to trigger UAF, as all all irqfds and thus all IRTEs are cleaned up by: kvm_irqfd_release() | |-> irqfd_deactivate() | |-> irqfd_shutdown() | |-> irq_bypass_unregister_consumer() And kvm_irqfd_release() is guaranteed to run before the last reference to the VM is put. KVM also configures GA Log interrupts only when a vCPU is blocking (older versions of KVM configre GA Log interrupts at all times, but AVIC is off by default on those kernels). Hitting UAF would require tearing down a VM shortly after a vCPU stopped blocking, and with a very, very delayed IRQ from hardware. Opportunistically use guard() to avoid a local "flags" variable. Fixes: 5881f73757cc ("svm: Introduce AMD IOMMU avic_ga_log_notifier") Cc: Naveen N Rao (AMD) <naveen@kernel.org> Cc: Xiao Wu <xiaowu.417@qq.com> Reviewed-by: Naveen N Rao (AMD) <naveen@kernel.org> Link: https://patch.msgid.link/20260630210156.457151-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-08KVM: SVM: Do all per-VM AVIC initialization during vCPU precreation phaseSean Christopherson
Move all per-VM AVIC initialization from VM creation to vCPU pre-creation, i.e. defer allocating the logical ID table and adding the VM to the GA Log list until vCPUs are created. This will allow removing the VM from the GA Log list before vCPUs are destroyed without needing yet another kvm_x86_ops hook (.vm_pre_destroy() is very intentionally called if and only if VM creation fully succeeds). As a bonus, this re-unites physical and logic table allocation, and avoids allocating a logical table in the unlikely scenario that userspace creates a VM without an in-kernel local APIC. Another bonus to hooking .vcpu_precreate() is that there is no need to unwind on failure, as the VM has already been created, i.e. KVM will run through all phases of VM destruction. In fact, unwinding is undesirable, as KVM tries to keep VM-wide behavior idempotent/sticky across creaton of multiple vCPUs. Reviewed-by: Naveen N Rao (AMD) <naveen@kernel.org> Link: https://patch.msgid.link/20260630210156.457151-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-08KVM: SVM: Make kvm_x86_ops.vcpu_precreate() hook fully AVIC specificSean Christopherson
In anticipation of deferring all per-VM AVIC initialization until a vCPU is first created, move SVM's kvm_x86_ops.vcpu_precreate() hook into avic.c as avic_vcpu_precreate() and nullify the hook if AVIC is disabled (and WARN if the hook is somehow invoked without AVIC enabled). Reviewed-by: Naveen N Rao (AMD) <naveen@kernel.org> Link: https://patch.msgid.link/20260630210156.457151-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-08KVM: x86: Move "struct kvm_vcpu_hv" and all children from kvm_host.h => hyperv.hSean Christopherson
Move "struct kvm_vcpu_hv" and all of its child structures to hyperv.h, guarded by CONFIG_KVM_HYPERV=y, as "struct kvm_vcpu_arch" holds a pointer to the structure, i.e. only needs the structure to be declared, not fully defined. No functional change intended. Reviewed-by: Kai Huang <kai.huang@intel.com> Link: https://patch.msgid.link/20260625220450.3354415-10-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-08KVM: x86: Move "struct kvm_apic_map" definition from kvm_host.h => lapic.hSean Christopherson
Move the definition of "struct kvm_apic_map", a.k.a. the optimized local APIC map, to lapic.h, as it is very nearly an implementation details that's internal to KVM's local APIC emulation (KVM also uses the map to do quick lookups when a vCPU is yielding to a different vCPU). No functional change intended. Suggested-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Link: https://patch.msgid.link/20260625220450.3354415-9-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>