summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2026-05-13ARM: zte: Add zx297520v3 platform supportStefan Dösinger
This SoC is used in low end LTE-to-WiFi routers, for example some D-Link DWR 932 revisions, ZTE K10, ZLT S10 4G, but also models that are branded and sold by ISPs themselves. They are widespread in Africa, China, Russia and Eastern Europe. This SoC is a relative of the zx296702 and zx296718 that had some upstream support until commit 89d4f98ae90d ("ARM: remove zte zx platform"). Reviewed-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com> --- Patch changelog: v8: * Select ARM_PSCI_FW (Sashiko). This is an issue make defconfig pointed out in the last patch in this series. The board does not have PSCI firmware as far as I can tell, but the ARM_GIC_V3 option indirectly assumes ARM_PSCI_FW is enabled. * Include <linux/init.h> in the board file for __initdata (Sashiko), removed other includes copypasted from another platform that aren't needed. Let's see if Sashiko agrees. * Add the SoC documentation to the documentation index (Sashiko) * Add the SoC documentation to MAINTAINERS (Sashiko) * Removed redundant if ARCH_ZTE (Sashiko) * Point towards a sane (USB-Only) U-Boot and modify the example code for booting from NAND to detect already fixed GIC setups.
2026-05-13Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds
Pull kvm fixes from Paolo Bonzini: "arm64: - Add the pKVM side of the workaround for ARM's erratum 4193714, provided that the EL3 firmware does its part of the job. KVM will refuse to initialise otherwise - Correctly handle 52bit VAs for guest EL2 stage-1 translations when running under NV with E2H==0 - Correctly deal with permission faults in guest_memfd memslots - Fix the steal-time selftest after the infrastructure was reworked - Make sure the host cannot pass a non-sensical clock update to the EL2 tracing infrastructure - Appoint Steffen Eiden as a reviewer in anticipation of the KVM/s390 ability to run arm64 guests, which will inevitably lead to arm64 code being directly used on s390 - Make sure that EL2 is configured with both exception entry and exit being Context Synchronization Events - Handle the current vcpu being NULL on EL2 panic - Fix the selftest_vcpu memcache being empty at the point of donation or sharing - Check that the memcache has enough capacity before engaging on the share/donate path - Fix __deactivate_fgt() to use its parameter rather than a variable in the macro context s390: - Fix array overrun with large amounts of PCI devices x86: - Never use L0's PAUSE loop exiting while L2 is running, since it's unlikely that a nested guest will help solving the hypervisor's spinlock contention - Fix emulation of MOVNTDQA - Fix typo in Xen hypercall tracepoint - Add back an optimization that was left behind when recently fixing a bug - Add module parameter to disable CET, whose implementation seems to have issues. For now it remains enabled by default Generic: - Reject offset causing an unsigned overflow in kvm_reset_dirty_gfn() Documentation: - Update stale links Selftests: - Fix guest_memfd_test with host page size > guest page size" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (22 commits) KVM: VMX: introduce module parameter to disable CET KVM: x86: Swap the dst and src operand for MOVNTDQA KVM: x86: use again the flush argument of __link_shadow_page() KVM: selftests: Ensure gmem file sizes are multiple of host page size Documentation: kvm: update links in the references section of AMD Memory Encryption KVM: nSVM: Never use L0's PAUSE loop exiting while L2 is running KVM: x86: Fix Xen hypercall tracepoint argument assignment KVM: Reject wrapped offset in kvm_reset_dirty_gfn() KVM: arm64: Pre-check vcpu memcache for host->guest donate KVM: arm64: Pre-check vcpu memcache for host->guest share KVM: arm64: Seed pkvm_ownership_selftest vcpu memcache KVM: arm64: Fix __deactivate_fgt macro parameter typo KVM: arm64: Guard against NULL vcpu on VHE hyp panic path KVM: arm64: Make EL2 exception entry and exit context-synchronization events MAINTAINERS: Add Steffen as reviewer for KVM/arm64 KVM: arm64: Remove potential UB on nvhe tracing clock update KVM: selftests: arm64: Fix steal_time test after UAPI refactoring KVM: arm64: Handle permission faults with guest_memfd KVM: arm64: nv: Consider the DS bit when translating TCR_EL2 KVM: arm64: Work around C1-Pro erratum 4193714 for protected guests ...
2026-05-13KVM: TDX: Fix x2APIC MSR handling in tdx_has_emulated_msr()Rick Edgecombe
Rework tdx_has_emulated_msr() to explicitly enumerate the x2APIC MSRs that KVM can emulate, instead of trying to enumerate the MSRs that KVM cannot emulate. Drop the inner switch and list the emulatable x2APIC registers directly in the outer switch's "return true" block. The old code had multiple bugs in the x2APIC range handling. X2APIC_MSR(APIC_ISR + APIC_ISR_NR) was incorrect because APIC_ISR_NR is 0x8, not 0x80, so the X2APIC_MSR() shift lost the lower bits, collapsing each range to a single MSR. IA32_X2APIC_SELF_IPI was also missing from the non-emulatable list. Note, these bugs are relatively benign, as they only affect a guest that is requesting "bogus" emulation. KVM has no visibility into whether or not a guest has enabled #VE reduction, which changes which MSRs the TDX-Module handles itself versus triggering a #VE for the guest to make a TDVMCALL. So maintaining a list of non-emulatable MSRs is fragile. Listing only the MSRs KVM can always emulate sidesteps the problem. Suggested-by: Sean Christopherson <seanjc@google.com> Reported-by: Dmytro Maluka <dmaluka@chromium.org> Closes: https://lore.kernel.org/all/20260318190111.1041924-1-dmaluka@chromium.org Fixes: dd50294f3e3c ("KVM: TDX: Implement callbacks for MSR operations") Assisted-by: Claude:claude-opus-4-6 [based on a diff from Sean, but added missed LVTCMCI case, log] Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://patch.msgid.link/20260410232654.3864196-1-rick.p.edgecombe@intel.com [sean: call out the bugs are relatively benign, expand comment] Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: x86: Make "external SPTE" ops that can fail RET0 static callsSean Christopherson
Define kvm_x86_ops .link_external_spt(), .set_external_spte(), and .free_external_spt() as RET0 static calls so that an unexpected call to a a default operation doesn't consume garbage. Fixes: 77ac7079e66d ("KVM: x86/tdp_mmu: Propagate building mirror page tables") Fixes: 94faba8999b9 ("KVM: x86/tdp_mmu: Propagate tearing down mirror page tables") Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Link: https://patch.msgid.link/20260129011517.3545883-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: TDX: Account all non-transient page allocations for per-TD structuresSean Christopherson
Account all non-transient allocations associated with a single TD (or its vCPUs), as KVM's ABI is that allocations that are active for the lifetime of a VM are accounted. Leave temporary allocations, i.e. allocations that are freed within a single function/ioctl, unaccounted, to again align with KVM's existing behavior, e.g. see commit dd103407ca31 ("KVM: X86: Remove unnecessary GFP_KERNEL_ACCOUNT for temporary variables"). Fixes: 8d032b683c29 ("KVM: TDX: create/destroy VM structure") Fixes: a50f673f25e0 ("KVM: TDX: Do TDX specific vcpu initialization") Cc: stable@vger.kernel.org Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Link: https://patch.msgid.link/20260129011517.3545883-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: x86/mmu: Update iter->old_spte if cmpxchg64 on mirror SPTE "fails"Sean Christopherson
Pass a pointer to iter->old_spte, not simply its value, when setting an external SPTE in __tdp_mmu_set_spte_atomic(), so that the iterator's value will be updated if the cmpxchg64 to freeze the mirror SPTE fails. The bug is currently benign as TDX is mutualy exclusive with all paths that do "local" retry", e.g. clear_dirty_gfn_range() and wrprot_gfn_range(). Fixes: 77ac7079e66d ("KVM: x86/tdp_mmu: Propagate building mirror page tables") Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Link: https://patch.msgid.link/20260129011517.3545883-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13x86/tdx: Use pg_level in TDX APIs, not the TDX-Module's 0-based levelSean Christopherson
Rework the TDX APIs to take the kernel's 1-based pg_level enum, not the TDX-Module's 0-based level. The APIs are _kernel_ APIs, not TDX-Module APIs, and the kernel (and KVM) uses "enum pg_level" literally everywhere. Using "enum pg_level" eliminates ambiguity when looking at the APIs (it's NOT clear that "int level" refers to the TDX-Module's level), and will allow for using existing helpers like page_level_size() when support for hugepages is added to the S-EPT APIs. No functional change intended. Cc: Kai Huang <kai.huang@intel.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: Yan Zhao <yan.y.zhao@intel.com> Cc: Vishal Annapurve <vannapurve@google.com> Cc: Ackerley Tng <ackerleytng@google.com> Acked-by: Kiryl Shutsemau <kas@kernel.org> Reviewed-by: Kai Huang <kai.huang@intel.com> Tested-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Tested-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20260129011517.3545883-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: x86: Drop superfluous caching of KVM_ASYNC_PF_SEND_ALWAYSSean Christopherson
Drop kvm_vcpu_arch.apf.send_always and instead use msr_en_val as the source of truth to reduce the probability of operating on stale data. This fixes flaws where KVM fails to update send_always when APF is explicitly disabled by the guest or implicitly disabled by KVM on INIT. Absent other bugs, the flaws are benign as KVM *shouldn't* consume send_always when PV APF support is disabled. Simply delete the field, as there's zero benefit to maintaining a separate "cache" of the state. Opportunistically turn the enabled vs. disabled logic at the end of kvm_pv_enable_async_pf() into an if-else instead of using an early return, e.g. so that it's more obvious that both paths are "success" paths. Fixes: 6adba5274206 ("KVM: Let host know whether the guest can handle async PF in non-userspace context.") Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://patch.msgid.link/20260406225359.1245490-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: x86: Drop superfluous caching of KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXITSean Christopherson
Drop kvm_vcpu_arch.apf.delivery_as_pf_vmexit and instead use msr_en_val as the source of truth to reduce the probability of operating on stale data. This fixes flaws where KVM fails to update delivery_as_pf_vmexit when APF is explicitly disabled by the guest or implicitly disabled by KVM on INIT. Absent other bugs, the flaws are benign as KVM *shouldn't* consume delivery_as_pf_vmexit when PV APF support is disabled. Simply delete the field, as there's zero benefit to maintaining a separate "cache" of the state. Fixes: 52a5c155cf79 ("KVM: async_pf: Let guest support delivery of async_pf from guest mode") Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://patch.msgid.link/20260406225359.1245490-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: x86: Don't leave APF half-enabled on bad APF data GPAEthan Yang
kvm_pv_enable_async_pf() updates vcpu->arch.apf.msr_en_val before initializing the APF data gfn_to_hva cache. If userspace provides an invalid GPA, kvm_gfn_to_hva_cache_init() fails, but msr_en_val stays enabled and leaves APF state half-initialized. Later APF paths can then try to use the empty cache and trigger WARN_ON() in kvm_read_guest_offset_cached(). Determine the new APF enabled state from the incoming MSR value, do cache initialization first on the enable path, and commit msr_en_val only after successful initialization. Keep the disable path behavior unchanged. Reported-by: syzbot+bc0e18379a290e5edfe4@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bc0e18379a290e5edfe4 Fixes: 344d9588a9df ("KVM: Add PV MSR to enable asynchronous page faults delivery.") Link: https://lore.kernel.org/r/aHfD3MczrDpzDX9O@google.com Suggested-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Ethan Yang <ethan.yang.kernel@gmail.com> [sean: don't bother with a local "enable" variable] Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://patch.msgid.link/20260406225359.1245490-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: x86: Rate-limit global clock updates on vCPU loadLei Chen
commit 446fcce2a52b ("Revert "x86: kvm: rate-limit global clock updates"") dropped the rate limiting for KVM_REQ_GLOBAL_CLOCK_UPDATE. As a result, kvm_arch_vcpu_load() can queue global clock update requests every time a vCPU is scheduled when the master clock is disabled or when the vCPU is loaded for the first time. Restore the throttling with a per-VM ratelimit state and gate KVM_REQ_GLOBAL_CLOCK_UPDATE through __ratelimit(), so frequent vCPU scheduling does not generate a steady stream of redundant clock update requests. Fixes: 446fcce2a52b ("Revert "x86: kvm: rate-limit global clock updates"") Signed-off-by: Lei Chen <lei.chen@smartx.com> Reported-by: Jaroslav Pulchart <jaroslav.pulchart@gooddata.com> Closes: https://lore.kernel.org/all/CAK8fFZ5gY8_Mw2A=iZVFNVKQNrXQzVsn-HTd+Me9K6ZfmdgA+Q@mail.gmail.com/ Link: https://patch.msgid.link/20260409142226.2581-1-lei.chen@smartx.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT pathAshutosh Desai
In sev_dbg_crypt(), the per-iteration transfer length is bounded by the source page offset (PAGE_SIZE - s_off) but not by the destination page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt path (__sev_dbg_encrypt_user) performs a read-modify-write using a single-page intermediate buffer (dst_tpage): 1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16) before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE, the PSP writes beyond the end of the 4096-byte dst_tpage allocation. 2. The subsequent memcpy()/copy_from_user() into page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition. Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE - the PSP is instructed to write round_up(4097, 16) = 4112 bytes to a 4096-byte buffer. Fix by also bounding len by (PAGE_SIZE - d_off), the same check that sev_send_update_data() already performs for its single-page guest region. ================================================================== BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd] Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214 CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: <TASK> dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [kvm] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint Fixes: 24f41fb23a39 ("KVM: SVM: Add support for SEV DEBUG_DECRYPT command") Fixes: 7d1594f5d94b ("KVM: SVM: Add support for SEV DEBUG_ENCRYPT command") Cc: stable@vger.kernel.org Signed-off-by: Ashutosh Desai <ashutoshdesai993@gmail.com> [sean: add sample KASAN splat, Fixes, and stable@] Link: https://patch.msgid.link/20260501203537.2120074-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: SEV: Don't advertise VM types that are disabled by firmwareTycho Andersen
As called out in a footnote for a recent SNP vulnerability[1], it is possible for a specific flavor of SEV+ to be disabled by the firmware even when the flavor is fully supported by the CPU and platform: Applying mitigation CVE-2025-48514 will result in disabling SEV-ES when SEV-SNP is enabled. Restrict KVM's set of supported VM types based on the VM types that are fully supported by firmware to avoid over-reporting what KVM can actually support. Like KVM's handling of ASID space exhaustion, don't modify KVM's CPUID capabilities, as the CPU/platform still supports the underlying technology and clearing e.g. SEV_ES while advertising SEV_SNP would confuse KVM and userspace. Link: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3023.html [1] Link: https://lore.kernel.org/all/aZyLIWtffvEnmtYh@google.com Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> [sean: rewrite changelog to provide details on why/how this can happen] Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Tested-by: Tycho Andersen (AMD) <tycho@kernel.org> Link: https://patch.msgid.link/20260416232329.3408497-7-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: SEV: Don't advertise support for unusable VM typesSean Christopherson
Commit 0aa6b90ef9d7 ("KVM: SVM: Add support for allowing zero SEV ASIDs") made it possible to make it impossible to use SEV VMs by not allocating them any ASIDs. Commit 6c7c620585c6 ("KVM: SEV: Add SEV-SNP CipherTextHiding support") did the same thing for SEV-ES. Do not export KVM_X86_SEV(_ES)_VM as supported types if in either of these situations, so that userspace can use them to determine what is actually supported by the current kernel configuration. Also move the buildup to a local variable so it is easier to add additional masking in future patches. Link: https://lore.kernel.org/all/aZyLIWtffvEnmtYh@google.com/ Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> [sean: land code in sev_hardware_setup()] Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Tested-by: Tycho Andersen (AMD) <tycho@kernel.org> Link: https://patch.msgid.link/20260416232329.3408497-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: SEV: Consolidate logic for printing state of SEV{,-ES,-SNP} enablingSean Christopherson
Add a helper to print enabled/unusable/disabled for SEV+ VM types in anticipation of SNP also being subjecting to "unusable" logic. No functional change intended. Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Tested-by: Tycho Andersen (AMD) <tycho@kernel.org> Link: https://patch.msgid.link/20260416232329.3408497-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: SEV: Set supported SEV+ VM types during sev_hardware_setup()Sean Christopherson
Set the supported SEV+ VM types during sev_hardware_setup() instead of waiting until sev_set_cpu_caps(). This will using the set of *fully* supported VM types to print the enabled/unusable/disabled messaged. For all intents and purposes, no functional change intended. Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Tested-by: Tycho Andersen (AMD) <tycho@kernel.org> Link: https://patch.msgid.link/20260416232329.3408497-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: SVM: Refresh vcpu->arch.cr{0,3} prior to invoking fastpath handlerSean Christopherson
Refresh KVM's copies of CR0 and CR3 from the VMCB prior to (potentially) invoking a fastpath handler to ensure that KVM doesn't consume stale state. While it's unlikely KVM will ever consume CR3 or CR0.{TS,MP} in the fastpath, grabbing the values from the VMCB is inexpensive, i.e. the risk of subtle bugs far outweighs the reward of deferring reads for a small subset of VM-Exits. Note, KVM doesn't currently consume CR3 or CR0.{TS,MP} in the fastpath, as KVM requires next_rip to be valid (i.e. KVM doesn't read CR3 to decode the instruction), CR0.MP is never consumed, and CR0.TS is only consumed by the full emulator. Reviewed-by: Nikunj A. Dadhania <nikunj@amd.com> Link: https://patch.msgid.link/20260423162628.490962-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: x86: Ensure vendor's exit handler runs before fastpath userspace exitsSean Christopherson
Move the handling of fastpath userspace exits into vendor code to ensure KVM runs vendor specific operations that need to run before userspace gains control of the vCPU. E.g. for VMX (and soon to be for SVM as well), KVM needs to flush the PML buffer prior to exiting to userspace, otherwise any memory written by the final KVM_RUN might never be flagged as dirty. Note, waiting to snapshot CR0 and CR3 until svm_handle_exit() is flawed in general, as that risks consuming stale state in a fastpath handler. That will be addressed in a future change. Fixes: f7f39c50edb9 ("KVM: x86: Exit to userspace if fastpath triggers one on instruction skip") Cc: stable@vger.kernel.org Cc: Nikunj A. Dadhania <nikunj@amd.com> Reviewed-by: Nikunj A. Dadhania <nikunj@amd.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Link: https://patch.msgid.link/20260423162628.490962-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13x86/virt: Silence RCU lockdep splat in emergency virt callback pathMikhail Gavrilov
x86_virt_invoke_kvm_emergency_callback() reaches rcu_dereference() through machine_crash_shutdown() with IRQs disabled but with RCU not necessarily watching the crashing CPU, which triggers a suspicious RCU usage splat on debug kernels (CONFIG_PROVE_RCU=y) during panic/kdump: WARNING: suspicious RCU usage arch/x86/virt/hw.c:52 suspicious rcu_dereference_check() usage! rcu_scheduler_active = 2, debug_locks = 1 1 lock held by tee/11119: #0: ffff8881fa32c440 (sb_writers#3){.+.+}-{0:0}, at: ksys_write Call Trace: <TASK> dump_stack_lvl+0x84/0xd0 lockdep_rcu_suspicious.cold+0x37/0x8f x86_virt_invoke_kvm_emergency_callback+0x5f/0x70 x86_svm_emergency_disable_virtualization_cpu+0x2a/0x30 x86_virt_emergency_disable_virtualization_cpu+0x6b/0x90 native_machine_crash_shutdown+0x72/0x170 __crash_kexec+0x137/0x280 panic+0xce/0xd0 sysrq_handle_crash+0x1f/0x20 __handle_sysrq.cold+0x192/0x335 write_sysrq_trigger+0x8c/0xc0 proc_reg_write+0x1c3/0x3c0 vfs_write+0x1d0/0xf80 ksys_write+0x116/0x250 do_syscall_64+0x11c/0x1480 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> A truly correct fix is non-trivial: the RCU usage genuinely is wrong in panic context (RCU may ignore the crashing CPU during synchronization), and a concurrent KVM module unload could in principle race with the callback read; see commit 2baa33a8ddd6 ("KVM: x86: Leave user-return notifier registered on reboot/shutdown") which notes that nothing prevents module unload during panic/reboot. However, the alternatives are worse: - smp_store_release()/smp_load_acquire() handles ordering but not liveness; the kernel still needs to keep the module text alive while the callback is in flight. - Taking a lock in the panic path is risky — any lock could be held by a CPU that has already been NMI'd to a halt. Use rcu_dereference_raw() to silence the splat and accept the vanishingly small remaining race. Panic context inherently cannot guarantee complete correctness; the goal here is to keep debug builds quiet on the kdump path so the splat doesn't obscure the actual kernel state being captured. Reproducible on a debug kernel (CONFIG_PROVE_LOCKING=y, CONFIG_PROVE_RCU=y) with kvm_amd or kvm_intel loaded by triggering kdump: echo c > /proc/sysrq-trigger Suggested-by: Sean Christopherson <seanjc@google.com> Fixes: 428afac5a8ea ("KVM: x86: Move bulk of emergency virtualizaton logic to virt subsystem") Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Acked-by: Sean Christopherson <seanjc@google.com> Link: https://patch.msgid.link/20260504235435.90957-1-mikhail.v.gavrilov@gmail.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: Rename invalidate_begin to invalidate_start for consistencyTakahiro Itazuri
Rename kvm_mmu_invalidate_begin() to kvm_mmu_invalidate_start() to align with mmu_notifier_ops.invalidate_range_start(), which is the callback that ultimately drives KVM's MMU invalidation. While the naming within KVM itself is a close split between "_begin" and "_start": $ git grep -E "invalidate(_range)?_begin" **/kvm* | wc -l 12 $ git grep -E "invalidate(_range)?_start" **/kvm* | wc -l 21 All two of the begin() uses are in KVM: $ git grep -E "invalidate(_range)?_begin" * | wc -l 14 And those two holdouts are bugs in invalidate_range_start()'s comment, i.e. will also be fixed sooner or later[*]. On the other hand, use of _start() is pervasive throughout the kernel: $ git grep -E "invalidate(_range)?_start" * | wc -l 117 Even if that weren't the case, conforming to the mmu_notifier_ops naming is the right call since invalidate_range_start() is the external API that KVM hooks into. No functional change intended. Link: https://lore.kernel.org/all/20260513163546.1176742-1-seanjc@google.com [*] Signed-off-by: Takahiro Itazuri <itazur@amazon.com> Link: https://patch.msgid.link/20260420154720.29012-4-itazur@amazon.com [sean: massage changelog to provide more (accurate) numbers] Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13Merge branch 'kvm-apx-prepare' into HEADPaolo Bonzini
Clean up KVM's register tracking and storage, primarily to prepare for APX support, which expands the maximum number of GPRs from 16 to 32.
2026-05-13KVM: x86: Use a proper bitmap for tracking available/dirty registersSean Christopherson
Define regs_{avail,dirty} as bitmaps instead of U32s to harden against overflow, and to allow for dynamically sizing the bitmaps when APX comes along, which will add 16 more GPRs (R16-R31) and thus increase the total number of registers beyond 32. Open code writes in the "reset" APIs, as the writes are hot paths and bitmap_write() is complete overkill for what KVM needs. Even better, hardcoding writes to entry '0' in the array is a perfect excuse to assert that the array contains exactly one entry, e.g. to effectively add guard against defining R16-R31 in 32-bit kernels. For all intents and purposes, no functional change intended even though using bitmap_fill() will mean "undefined" registers are no longer marked available and dirty (KVM should never be querying those bits). Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Tested-by: Kai Huang <kai.huang@intel.com> Message-ID: <20260409224236.2021562-7-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-05-13KVM: x86: Track available/dirty register masks as "unsigned long" valuesSean Christopherson
Convert regs_{avail,dirty} and all related masks to "unsigned long" values as an intermediate step towards declaring the fields as actual bitmaps, and as a step toward support APX, which will push the total number of registers beyond 32 on 64-bit kernels. Opportunistically convert TDX's ULL bitmask to a UL to match everything else (TDX is 64-bit only, so it's a nop in the end). No functional change intended. Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Tested-by: Kai Huang <kai.huang@intel.com> Message-ID: <20260409224236.2021562-6-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-05-13KVM: x86: Add wrapper APIs to reset dirty/available register masksSean Christopherson
Add wrappers for setting regs_{avail,dirty} in anticipation of turning the fields into proper bitmaps, at which point direct writes won't work so well. Deliberately leave the initialization in kvm_arch_vcpu_create() as-is, because the regs_avail logic in particular is special in that it's the one and only place where KVM marks eagerly synchronized registers as available. No functional change intended. Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Tested-by: Kai Huang <kai.huang@intel.com> Message-ID: <20260409224236.2021562-5-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-05-13KVM: nVMX: Do a bitwise-AND of regs_avail when switching active VMCSSean Christopherson
When switching between vmcs01 and vmcs02, do a bitwise-AND of regs_avail to effectively reset the mask for the new VMCS, purely to be consistent with all other "full" writes of regs_avail. In practice, a straight write versus a bitwise-AND will yield the same result, as kvm_arch_vcpu_create() marks *all* registers available (and dirty), and KVM never marks registers unavailable unless they're lazily loaded. This will allow adding wrapper APIs to set regs_{avail,dirty} without having to add special handling for a nVMX use case that doesn't exist in practice. Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Tested-by: Kai Huang <kai.huang@intel.com> Message-ID: <20260409224236.2021562-4-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-05-13KVM: x86: Drop the "EX" part of "EXREG" to avoid collision with APXSean Christopherson
Now that NR_VCPU_REGS is no longer a thing, and now that now that RIP is effectively an EXREG, drop the "EX" is for extended (or maybe extra?") prefix from non-GPR registers to avoid a collision with APX (Advanced Performance Extensions), which adds: 16 additional general-purpose registers (GPRs) R16–R31, also referred to as Extended GPRs (EGPRs) in this document; I.e. KVM's version of "extended" won't match with APX's definition. No functional change intended. Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Tested-by: Kai Huang <kai.huang@intel.com> Message-ID: <20260409224236.2021562-3-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-05-13KVM: x86: Add dedicated storage for guest RIPSean Christopherson
Add kvm_vcpu_arch.rip to track guest RIP instead of including it in the generic regs[] array. Decoupling RIP from regs[] will allow using a *completely* arbitrary index for RIP, as opposed to the mostly-arbitrary index that is currently used. That in turn will allow using indices 16-31 to track R16-R31 that are coming with APX. Note, although RIP can used for addressing, it does NOT have an architecturally defined index, and so can't be reached via flows like get_vmx_mem_address() where KVM "blindly" reads a general purpose register given the SIB information reported by hardware. For RIP-relative addressing, hardware reports the full "offset" in vmcs.EXIT_QUALIFICATION. Note #2, keep the available/dirty tracking as RSP is context switched through the VMCS, i.e. needs to be cached for VMX. Opportunistically rename NR_VCPU_REGS to NR_VCPU_GENERAL_PURPOSE_REGS to better capture what it tracks, and so that KVM can slot in R16-R13 without running into weirdness where KVM's definition of "EXREG" doesn't line up with APX's definition of "extended reg". No functional change intended. Cc: Chang S. Bae <chang.seok.bae@intel.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Chang S. Bae <chang.seok.bae@intel.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Tested-by: Kai Huang <kai.huang@intel.com> Message-ID: <20260409224236.2021562-2-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-05-13bpf, arm64: Add JIT support for stack argumentsPuranjay Mohan
Implement stack argument passing for BPF-to-BPF and kfunc calls with more than 5 parameters on arm64, following the AAPCS64 calling convention. BPF R1-R5 already map to x0-x4. With BPF_REG_0 moved to x8 by the previous commit, x5-x7 are free for arguments 6-8. Arguments 9-12 spill onto the stack at [SP+0], [SP+8], ... and the callee reads them from [FP+16], [FP+24], ... (above the saved FP/LR pair). BPF convention uses fixed offsets from BPF_REG_PARAMS (r11): off=-8 is always arg 6, off=-16 arg 7, etc. The verifier invalidates all outgoing stack arg slots after each call, so the compiler must re-store before every call. This means x5-x7 don't need to be saved on stack. Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20260513045158.2402494-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-13bpf, arm64: Map BPF_REG_0 to x8 instead of x7Puranjay Mohan
Move the BPF return value register from x7 to x8, freeing x7 for use as an argument register. AAPCS64 designates x8 as the indirect result location register; it is caller-saved and not used for argument passing, making it a suitable home for BPF_REG_0. This is a prerequisite for stack argument support, which needs x5-x7 to pass arguments 6-8 to native kfuncs following the AAPCS64 calling convention. Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20260513045153.2402197-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-13bpf,x86: Implement JIT support for stack argumentsYonghong Song
Add x86_64 JIT support for BPF functions and kfuncs with more than 5 arguments. The extra arguments are passed through a stack area addressed by register r11 (BPF_REG_PARAMS) in BPF bytecode, which the JIT translates to native code. The JIT follows the x86-64 calling convention for both BPF-to-BPF and kfunc calls: - Arg 6 is passed in the R9 register - Args 7+ are passed on the stack Incoming arg 6 (BPF r11+8) is translated to a MOV from R9 rather than a memory load. Incoming args 7+ (BPF r11+16, r11+24, ...) map directly to [rbp + 16], [rbp + 24], ..., matching the x86-64 stack layout after CALL + PUSH RBP, so no offset adjustment is needed. tail_call_reachable is rejected by the verifier and priv_stack is disabled by the JIT when stack args exist, so R9 is always available. When BPF bytecode writes to the arg-6 stack slot (offset -8), the JIT emits a MOV into R9 instead of a memory store. Outgoing args 7+ are placed at [rsp] in a pre-allocated area below callee-saved registers, using: native_off = outgoing_arg_base - outgoing_rsp - bpf_off - 16 The native x86_64 stack layout with stack arguments: high address +-------------------------+ | incoming stack arg N | [rbp + 16 + (N-7)*8] (from caller) | ... | | incoming stack arg 7 | [rbp + 16] +-------------------------+ | return address | [rbp + 8] | saved rbp | [rbp] +-------------------------+ | BPF program stack | (round_up(stack_depth, 8) bytes) +-------------------------+ | callee-saved regs | (r12, rbx, r13, r14, r15 as needed) +-------------------------+ | outgoing arg M | [rsp + (M-7)*8] | ... | | outgoing arg 7 | [rsp] +-------------------------+ rsp low address Acked-by: Puranjay Mohan <puranjay@kernel.org> Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20260513045122.2393118-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-13x86/mce: Restore MCA polling interval halvingBorislav Petkov (AMD)
RongQing reported that the MCA polling interval doesn't halve when an error gets logged. It was traced down to the commit in Fixes:, because: mce_timer_fn() |-> mce_poll_banks() |-> machine_check_poll() |-> mce_log() which will queue the work and return. Now, back in mce_timer_fn(): /* * Alert userspace if needed. If we logged an MCE, reduce the polling * interval, otherwise increase the polling interval. */ if (mce_notify_irq()) <--- here we haven't ran the notifier chain yet so mce_need_notify is not set yet so this won't hit and we won't halve the interval iv. Now the notifier chain runs. mce_early_notifier() sets the bit, does mce_notify_irq(), that clears the bit and then the notifier chain a little later logs the error. So this is a silly timing issue. But, that's all unnecessary. All it needs to happen here is, the "should we notify of a logged MCE" mce_notify_irq() asks, should be simply a question to the mce gen pool: "Are you empty?" And that then turns into a simple yes or no answer and it all JustWorks(tm). So do that and also distribute the functionality where it belongs: - Print that MCE events have been logged in mce_log() - Trigger the mcelog tool specific work in the first notifier As a result, mce_notify_irq() can go now. Fixes: 011d82611172 ("RAS: Add a Corrected Errors Collector") Reported-by: Li RongQing <lirongqing@baidu.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Tested-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Link: https://lore.kernel.org/r/20260112082747.2842-1-lirongqing@baidu.com
2026-05-13KVM: VMX: introduce module parameter to disable CETPaolo Bonzini
There have been reports of host hangs caused by CET virtualization. Until these are analyzed further, introduce a module parameter that makes it possible to easily disable it. Link: https://lore.kernel.org/all/85548beb-1486-40f9-beb4-632c78e3360b@proxmox.com/ Cc: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-05-13arm64: dts: amlogic: t7: Add PWM pinctrl nodesRonald Claveau
These pinctrl nodes are required by the PWM drivers to configure pin muxing at runtime. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr> Link: https://patch.msgid.link/20260326-add-emmc-t7-vim4-v5-4-d3f182b48e9d@aliel.fr Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2026-05-13riscv: dts: spacemit: k3: Add USB2.0 supportYixun Lan
There is one USB2.0 host in K3 SoC which use DWC3 IP but only provide USB2.0 functionality, and with only one USB2 PHY connected. The USB2.0 controller on Pico-ITX board connects to a Terminus FE1.1 Hub which fully USB2.0 protocol compliant and provides 4 ports. Link: https://patch.msgid.link/20260330-02-k3-usb20-dts-v2-1-46af262fb4a9@kernel.org Signed-off-by: Yixun Lan <dlan@kernel.org>
2026-05-12Merge tag 'kvm-s390-master-7.1-1' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD KVM: s390: pci: fix array indexing For large amounts of PCI devices its possible to overrun the arrays as the index was miscalculated in 2 places.
2026-05-12KVM: x86: Swap the dst and src operand for MOVNTDQASean Christopherson
Swap the MOVNTDQA operands, as MOVNTDQA does NOT in fact have "the same characteristics as 0F E7 (MOVNTDQ)"; MOVNTDQA loads from memory and stores to registers, while MOVNTDQ loads from registers and stores to memory. Per the SDM: MOVNTDQ - Move packed integer values in xmm1 to m128 using non-temporal hint. MOVNTDQA - Move double quadword from m128 to xmm1 using non-temporal hint if WC memory type. Reported-by: Josh Eads <josheads@google.com> Fixes: c57d9bafbd0b ("KVM: x86: Add support for emulating MOVNTDQA") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20260506213514.2781948-1-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-05-12KVM: x86: use again the flush argument of __link_shadow_page()Paolo Bonzini
Except in the case of parentless nested-TDP pages, mmu_page_zap_pte() clears the SPTE but leaves the invalid_list empty. In this case, using kvm_flush_remote_tlbs() as kvm_mmu_remote_flush_or_zap() does is overkill. Avoid flushing the entirety of the remote TLBs unless the invalid_list was populated: instead, use a more efficient gfn-targeting flush (if available) and skip it altogether if the caller guarantees that a TLB flush is not necessary. Based-on: <20260503201029.106481-1-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-ID: <20260503210917.121840-1-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-05-12arm64: dts: qcom: sdm670: add lpi pinctrlRichard Acayan
The Snapdragon 670 has a separate TLMM for audio pins. Add the device node for it. Also add reserved GPIOs for the Pixel 3a, which blocks access to the sensor GPIOs. Signed-off-by: Richard Acayan <mailingradian@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Acked-by: Linus Walleij <linusw@kernel.org> Link: https://lore.kernel.org/r/20260331200658.1306-5-mailingradian@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-12arm64: dts: qcom: sm8450: Fix ICE reg sizeKuldeep Singh
The ICE register region size was originally described incorrectly when the ICE hardware was first introduced. The same value was later carried over unchanged when the ICE node was split out from the UFS node into its own DT entry. Correct the register size to match the hardware specification. Fixes: 276ee34a40c1 ("arm64: dts: qcom: sm8450: add Inline Crypto Engine registers and clock") Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260402-ice_dt_reg_fix-v1-2-74e4c2129238@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-12arm64: dts: qcom: kodiak: Fix ICE reg sizeKuldeep Singh
The ICE register region on Kodiak is currently defined as 0x8000 bytes. According to the hardware specification, the correct register size is 0x18000. Update the ICE node reg property to match the hardware. Fixes: dfd5ee7b34bb ("arm64: dts: qcom: sc7280: Add inline crypto engine") Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260402-ice_dt_reg_fix-v1-1-74e4c2129238@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-12arm64: dts: qcom: sm8750: Fix DSI1 phy reference clock rateKrzysztof Kozlowski
The DSI PHY CXO clock input is the SoC CXO divided by two. DSI0 already uses correct one, but DSI1 got copy-paste from SM8650. Wrong clock parent will cause incorrect DSI1 PHY PLL frequencies to be used making the DSI panel non-working, although there is no upstream user of DSI1. Fixes: 818ae2b389bc ("arm64: dts: qcom: sm8750: Add display (MDSS) with Display CC") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260331165645.233965-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-12arm64: dts: qcom: sm8550: add cpu OPP table with DDR, LLCC & L3 bandwidthsAaron Kling
Add the OPP tables for each CPU clusters (cpu0-1-2, cpu3-4-5-6 & cpu7) to permit scaling the Last Level Cache Controller (LLCC), DDR and L3 cache frequency by aggregating bandwidth requests of all CPU core with referenc to the current OPP they are configured in by the LMH/EPSS hardware. The effect is a proper caches & DDR frequency scaling when CPU cores changes frequency. The OPP tables were built using the downstream memlat ddr, llcc & l3 tables for each cluster types with the actual EPSS cpufreq LUT tables from running a QCS8550 device. Also add the OSC L3 Cache controller node. Also add the interconnect entry for each cpu, with 3 different paths: - CPU to Last Level Cache Controller (LLCC) - Last Level Cache Controller (LLCC) to DDR - L3 Cache from CPU to DDR interface Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-HDK Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Link: https://lore.kernel.org/r/20260330-sm8550-ddr-bw-scaling-v4-1-5020c06983a0@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-12arm64: dts: qcom: agatti: Add IPA nodesWojciech Slenska
Added IPA nodes and definitions. Signed-off-by: Wojciech Slenska <wojciech.slenska@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260310112309.79261-3-wojciech.slenska@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-12arm64: dts: qcom: x1-dell-thena: remove i2c20 (battery SMBus) and reserve ↵Val Packett
its pins i2c20 is used by the battmgr service on the ADSP to communicate with the SBS interface of the battery. Initializing it from Linux would break the battmgr functionality when booted in EL2. Mark those pins as reserved. Fixes: e7733b42111c ("arm64: dts: qcom: Add support for Dell Inspiron 7441 / Latitude 7455") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Signed-off-by: Val Packett <val@packett.cool> Link: https://lore.kernel.org/r/20260312005731.12488-2-val@packett.cool Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-12Merge tag 'kvmarm-fixes-7.1-2' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for 7.1, take #2 - Add the pKVM side of the workaround for ARM's erratum 4193714, provided that the EL3 firmware does its part of the job. KVM will refuse to initialise otherwise. - Correctly handle 52bit VAs for guest EL2 stage-1 translations when running under NV with E2H==0. - Correctly deal with permission faults in guest_memfd memslots. - Fix the steal-time selftest after the infrastructure was reworked. - Make sure the host cannot pass a non-sensical clock update to the EL2 tracing infrastructure. - Appoint Steffen Eiden as a reviewer in anticipation of the KVM/s390 ability to run arm64 guests, which will inevitably lead to arm64 code being directly used on s390. - Make sure that EL2 is configured with both exception entry and exit being Context Synchronization Events. - Handle the current vcpu being NULL on EL2 panic. - Fix the selftest_vcpu memcache being empty at the point of donation or sharing. - Check that the memcache has enough capacity before engaging on the share/donate path. - Fix __deactivate_fgt() to use its parameter rather than a variable in the macro context.
2026-05-12KVM: nSVM: Never use L0's PAUSE loop exiting while L2 is runningSean Christopherson
Never use L0's (KVM's) PAUSE loop exiting controls while L2 is running, and instead always configure vmcb02 according to L1's exact capabilities and desires. The purpose of intercepting PAUSE after N attempts is to detect when the vCPU may be stuck waiting on a lock, so that KVM can schedule in a different vCPU that may be holding said lock. Barring a very interesting setup, L1 and L2 do not share locks, and it's extremely unlikely that an L1 vCPU would hold a spinlock while running L2. I.e. having a vCPU executing in L1 yield to a vCPU running in L2 will not allow the L1 vCPU to make forward progress, and vice versa. While teaching KVM's "on spin" logic to only yield to other vCPUs in L2 is doable, in all likelihood it would do more harm than good for most setups. KVM has limited visibility into which L2 "vCPUs" belong to the same VM, and thus share a locking domain. And even if L2 vCPUs are in the same VM, KVM has no visilibity into L2 vCPU's that are scheduled out by the L1 hypervisor. Furthermore, KVM doesn't actually steal PAUSE exits from L1. If L1 is intercepting PAUSE, KVM will route PAUSE exits to L1, not L0, as nested_svm_intercept() gives priority to the vmcb12 intercept. As such, overriding the count/threshold fields in vmcb02 with vmcb01's values is nonsensical, as doing so clobbers all the training/learning that has been done in L1. Even worse, if L1 is not intercepting PAUSE, i.e. KVM is handling PAUSE exits, then KVM will adjust the PLE knobs based on L2 behavior, which could very well be detrimental to L1, e.g. due to essentially poisoning L1 PLE training with bad data. And copying the count from vmcb02 to vmcb01 on a nested VM-Exit makes even less sense, because again, the purpose of PLE is to detect spinning vCPUs. Whether or not a vCPU is spinning in L2 at the time of a nested VM-Exit has no relevance as to the behavior of the vCPU when it executes in L1. The only scenarios where any of this actually works is if at least one of KVM or L1 is NOT intercepting PAUSE for the guest. Per the original changelog, those were the only scenarios considered to be supported. Disabling KVM's use of PLE makes it so the VM is always in a "supported" mode. Last, but certainly not least, using KVM's count/threshold instead of the values provided by L1 is a blatant violation of the SVM architecture. Fixes: 74fd41ed16fd ("KVM: x86: nSVM: support PAUSE filtering when L0 doesn't intercept PAUSE") Cc: Maxim Levitsky <mlevitsk@redhat.com> Tested-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Link: https://patch.msgid.link/20260508213321.373309-1-seanjc@google.com/ Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-05-12KVM: x86: Fix Xen hypercall tracepoint argument assignmentQiang Ma
TRACE_EVENT(kvm_xen_hypercall) stores a5 in __entry->a4 instead of __entry->a5. That overwrites the recorded a4 argument and leaves a5 unset in the trace entry. Fix the typo so both arguments are captured correctly. Signed-off-by: Qiang Ma <maqianga@uniontech.com> Link: https://patch.msgid.link/20260512015313.1685784-1-maqianga@uniontech.com/ Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-05-12arm64: dts: qcom: sm8750: Add camera clock controllerTaniya Das
The camera clock controller is split into cambistmclk and camcc. The cambist clock controller handles the mclks and the rest of the clocks of camera are part of the camcc clock controller. Add the camcc clock controller device node for SM8750 SoC. Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260511-sm8750_camcc_dt-v4-1-eab4b6c3eaea@oss.qualcomm.com [bjorn: Fixed include file order] Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-12x86/microcode: Fix comment in microcode_loader_disabled()Xiaoyao Li
The code in microcode_loader_disabled() actually checks for the bit 31 in CPUID[1]:ECX being set. Update the comment to match the code. No functional change intended. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260512152754.671760-1-xiaoyao.li@intel.com
2026-05-12ARM: pxa: pxa27x: attach software node to its target GPIO controllerBartosz Golaszewski
Software node describing the GPIO controller for the pxa27x platforms is currently "dangling" - it's not actually attached to the relevant controller and doesn't allow real fwnode lookup. Attach it once it's registered as a firmware node before adding the platform device. Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260430-pxa-gpio-swnodes-v3-4-5142e95f0eca@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-07-19 13:26:24 +0000