summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2026-06-24KVM: x86: Move IRQ-related helper declarations from kvm_host.h => irq.hSean Christopherson
Move the function declaration for APIs to get/query pending IRQs from kvm_host.h to irq.h, as the APIs are only used by KVM x86 code. No functional change intended. Reviewed-by: Yosry Ahmed <yosry@kernel.org> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-25-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Move __kvm_irq_line_state() from kvm_host.h => ioapic.hSean Christopherson
Bury __kvm_irq_line_state() in CONFIG_KVM_IOAPIC=y code, as it's only used by PIC and I/O APIC code. No functional change intended. Reviewed-by: Yosry Ahmed <yosry@kernel.org> Reviewed-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-24-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Move misc "VALID MASK" defines from kvm_host.h => x86.cSean Christopherson
Move a variety of "VALID MASK" defines, e.g. that capture which flags in a given ioctl are supported by KVM, from kvm_host.h to x86.c. The set of valid flags/bits is very much a KVM-internal detail, as the values from the hardcoded #defines are often captured and massaged by KVM's setup code, i.e. *directly* using the macros outside of KVM x86 would be actively dangerous. No functional change intended. Reviewed-by: Yosry Ahmed <yosry@kernel.org> Reviewed-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-23-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Move LLDT assembly wrappers into VMXSean Christopherson
Move kvm_{load,read}_ldt() into vmx.c, as vmx_{load,store}_ldt(), as they are exclusively used by VMX to save/restore host state, and have no business being globally visible. Ideally, KVM-specific helpers wouldn't exist at all, as they are nothing more than assembly wrappers for SLDT and LLDT, i.e. should be provided by the kernel, not by KVM. Punt that cleanup to the future, as arch/x86/include/asm/desc.h _does_ provide helpers, but load_ldt() is only available for CONFIG_PARAVIRT_XXL=n builds, and both {load,store}_ldt() unnecessarily constrain the operands to memory. No functional change intended. Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-22-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Move MMU helper declarations from kvm_host.h => mmu.hSean Christopherson
Move a pile of MMU helper declarations and macros into mmu.h, as they are very much KVM x86 internal APIs and details, and not intended to be exposed to arch-neutral KVM, and certainly not to the broader kernel. No functional change intended. Reviewed-by: Yosry Ahmed <yosry@kernel.org> Reviewed-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-21-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86/pmu: Move "struct kvm_x86_pmu_event_filter" definition to pmu.cSean Christopherson
Move the definition of "struct kvm_x86_pmu_event_filter" to pmu.c, as the as the details of the filters are very much implementation details that can and should be buried in pmu.c. While the _existence_ of filters is public knowledge, almost by definition, the contents don't need to be exposed outside of the PMU code as the filter data is provided by userspace, i.e. it pretty much has to be dynamically allocated, and thus never should be fully embedded in a globally visible structure. No functional change intended Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-20-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Move "struct kvm_x86_msr_filter" definition to msrs.cSean Christopherson
Move the definition of "struct kvm_x86_msr_filter" and its associate, "struct msr_bitmap_range", to msrs.c, as the details of the filters are very much implementation details that can and should be buried in msrs.c. While the _existence_ of filters is public knowledge, almost by definition, the contents don't need to be exposed outside of the MSR code as the filter data is provided by userspace, i.e. it pretty much has to be dynamically allocated, and thus never should be fully embedded in a globally visible structure. Note, this creates a discrepancy with the PMU event filter structure; that will be remedied shortly. No functional change intended. Suggested-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-19-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Move MSR helper declarations from kvm_host.h => msrs.hSean Christopherson
Relocate declarations of MSR helpers (and kvm_nr_uret_msrs) from x86's kvm_host.h to msrs, to continue trimming down kvm_host.h. Deliberately leave the funky read_msr() where it is, as it will hopefully be removed entirely as part of a broader kernel-API cleanup. No functional change intended. Reviewed-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-18-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Move kvm_{g,s}et_segment() to inline helpers in regs.hSean Christopherson
Define kvm_{g,s}et_segment() as inline functions in regs.h, as they are literally one-line wrappers to invoke vendor code. No functional change intended. Reviewed-by: Yosry Ahmed <yosry@kernel.org> Reviewed-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-17-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Move register helper declarations from kvm_host.h => regs.hSean Christopherson
Relocate declarations of Control/Debug Register, EFLAGS and RIP helpers from x86's kvm_host.h to regs.h, to continue trimming down kvm_host.h. No functional change intended. Reviewed-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-16-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Move the bulk of MSR specific code from x86.c to msrs.{c,h}Sean Christopherson
Introduce msrs.{c,h}, and move the vast majority of MSR specific code out of x86.{c,h}. Use a plural "msrs" instead of just "msr" to be consistent with regs.{c,h}, and to make it easier to differentiate KVM's code from the other 5+ msr.c files in the kernel. Opportunistically drop the "x86.h" include from mtrr.c, mostly as proof that the bulk of the MSR code is indeed being relocated to msrs.c. No functional change intended. Reviewed-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-15-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Expose several TSC helpers via x86.h for use by MSR codeSean Christopherson
Begrudgingly move adjust_tsc_offset_{guest,host}() to x86.h as inlines, and expose several other TSC helpers in anticipation of moving KVM's MSR code to a dedicated msrs.c. Unfortunately for KVM, several MSRs that KVM emulates can affect TSC state. Opportunistically drop a superfluous local "tsc_offset" variable, whose existence causes checkpatch to complain about lack of a blank line. No functional change intended. Reviewed-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20260613000329.732085-14-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Extract get/set MSR (list) ioctl logic to helpersSean Christopherson
Extract the code for getting/setting MSRs and MSR lists to dedicated helpers in anticipation of moving the MSR code to a new msrs.c. No functional change intended. Reviewed-by: Yosry Ahmed <yosry@kernel.org> Reviewed-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-13-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Move kvm_{load,put}_guest_fpu() to fpu.hSean Christopherson
Move the kvm_{load,put}_guest_fpu() helpers to fpu.h in anticipation of moving the bulk of KVM's MSR handling code out of x86.c. KVM needs to load and put the FPU when accessing MSRs that are managed via XSTATE, a.k.a. the so called "FPU". No functional change intended. Reviewed-by: Yosry Ahmed <yosry@kernel.org> Reviewed-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-12-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86/hyperv: Eliminate an unnecessary include of x86.h in hyperv.hSean Christopherson
Drop an mostly unused include of x86.h from hyperv.h, and instead pull in regs.h, which is need for at least is_guest_mode(). This eliminates the last include of x86.h from a common x86 header, i.e. solidifies that x86.h is the top of the pyramid. Add a missing x86.h include in cpuid.c to avoid build breakage. No functional change intended. Reviewed-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-11-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Move eager_page_split to mmu.{c,h}Sean Christopherson
Move KVM's eager_page_split module param to the MMU, as it is very much an MMU knob. No functional change intended. Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Yosry Ahmed <yosry@kernel.org> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-10-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Move tdp_enabled from kvm_host.h to mmu.hSean Christopherson
Relocated the declaration of tdp_enabled into mmu.h, and opportunistically hoist tdp_mmu_enabled up to the top so that the two are co-located. No functional change intended. Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Yosry Ahmed <yosry@kernel.org> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-9-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Swap the include order between x86.h and mmu.hSean Christopherson
Invert the include ordering between x86.h and mmu.h, and move mmu_is_nested() to mmu.h where it belongs (mmu_is_nested()'s placement in x86.h was solely responsible for the existing ordering), so that x86.h is not included by most KVM internal headers (but includes them). No functional change intended. Reviewed-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-8-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Move kvm_caps and kvm_host_values to asm/kvm_host.hSean Christopherson
Relocate the kvm_caps and kvm_host_values struct definitions and their associated global variable declarations to asm/kvm_host.h to allow for a variety of cleanups in x86.h and mmu.h, and to establish a (hopefully) maintainable rule that asm/kvm_host.h's role is to define common structures (and declare any associated globals), and anything needed by arch-neutral KVM. While it would be lovely to trim kvm_host.h down to the point where it *only* holds things needed by arch-neutral and/or non-KVM code, multiple attempts to do just that have failed miserably. Trying to "hide" code from arch-neutral KVM is too restrictive (and ultimately pointless), and KVM x86 itself also needs a place to define common structures and their globals, e.g. to avoid inconsistent header include chains and/or misplaced helpers. E.g. as pointed out by Kai, it's weird that x86.h, which is a kitchen sink of sorts, includes regs.h, but not mmu.h. Literally the only reason that x86.h doesn't include mmu.h is that mmu.h references kvm_host, which is currently defined in x86.h. As a result of odd include ordering, the very clearly MMU-specific helper mmu_is_nested() lives in x86.h, not mmu.h "Fix" the kvm_host dependency so that x86.h can be the "central" include everyone expects it to be, and set KVM x86 on the path to having somewhat sensible "rules" for what goes where: - asm/kvm_host.h holds "common" structure definitions and associated key global variables, and things that are referenced by arch-neutral KVM. - <thing>.{c,h} holds relevant declarations and definitions. - x86.{c,h} is the kitchen sink for everything else. Cc: Kai Huang <kai.huang@intel.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Yosry Ahmed <yosry@kernel.org> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20260613000329.732085-7-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Move local APIC specific helpers out of asm/kvm_host.hSean Christopherson
Move local APIC IRQ helpers out of asm/kvm_host.h so that they are co-located with the structs they use, and exposed to a smaller portion of the broader world. No functional change intended. Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Yosry Ahmed <yosry@kernel.org> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-6-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Move the bulk of register specific code from x86.c to regs.cSean Christopherson
Introduce regs.c, and move the vast majority of register specific code out of x86.c and into regs.c. Deliberately leave behind MSR code, as KVM's MSR support is complex enough to warrant its own compilation unit, and doesn't have much in common with the other register code. Note, "struct kvm_sregs" has fields for EFER and MSR_IA32_APICBASE, and so the {G,S}ET_REGS flows technically contain a tiny amount of MSR code. MSR_IA32_APICBASE is already managed by lapic.c, and so doesn't require a "placement decision". As for EFER, leave all other EFER handling in x86.c (later to be moved to msrs.c). The primary interface to EFER, set_efer(), is very much MSR specific, even though EFER is arguably more of a Control Register than an MSR. No functional change intended. Reviewed-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-5-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Rename __{g,s}et_sregs2() => kvm_vcpu_ioctl_x86_{g,s}et_sregs2()Sean Christopherson
Rename the KVM_{G,S}ET_SREGS2 helpers in anticipation of moving them out of x86.c (while leaving the ioctl dispatch behind). Having globally visible APIs named __{g,s}et_sregs2() would be "fine", but ugly, given that __{g,s}et_sregs() will NOT be globally visible. As a bonus, this makes it a bit more obvious that the helpers implement newer versions of kvm_arch_vcpu_ioctl_set_sregs(). No functional change intended. Cc: Yosry Ahmed <yosry@kernel.org> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Message-ID: <20260613000329.732085-4-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Move get_segment_base() to regs.h, as kvm_get_segment_base()Sean Christopherson
Move get_segment_base() to regs.h, as kvm_get_segment_base(), so that the bulk of the register code can be moved from x86.c to a new regs.c, without simultaneously needing to rename "public" helpers to explicitly scope them to KVM. No functional change intended. Cc: Yosry Ahmed <yosry@kernel.org> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-3-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Extract REGS and SREGS runtime sync code to helpersSean Christopherson
Extract the REGS and SREGS portions of {store,sync}_regs() into separate helpers in anticipation of moving the register specific code out of x86.c and into regs.c. No functional change intended. Cc: Yosry Ahmed <yosry@kernel.org> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Message-ID: <20260613000329.732085-2-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24x86/apic: KVM: Use cpu_physical_id() to get APIC ID of running vCPU for AVICSean Christopherson
Use cpu_physical_id() instead of default_cpu_present_to_apicid() when getting the APIC ID of the pCPU on which a vCPU is running/loaded, as the kernel has gone way off the rails if a vCPU is loaded on a pCPU that has been physically removed from the system. Even if the impossible were to happen, the absolutely worst case scenario is that hardware will ring the AIVC doorbell on the wrong pCPU, i.e. a severely broken system will experience mild performance issues. Kill off KVM's superfluous kvm_cpu_get_apicid() wrapper along with the for-KVM export of default_cpu_present_to_apicid(), as they existed purely for the wonky AVIC usage. Cc: Kai Huang <kai.huang@intel.com> Cc: Yosry Ahmed <yosry@kernel.org> Signed-off-by: Sean Christopherson <seanjc@google.com> Acked-by: Naveen N Rao (AMD) <naveen@kernel.org> Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Yosry Ahmed <yosry@kernel.org> Message-ID: <20260612185459.591892-1-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86/mmu: Expose number of shadow MMU shadow pages as a statSean Christopherson
Turn arch.n_used_mmu_pages into a stat, mmu_shadow_pages, as the number of live shadow pages is arguably _the_ most critical datapoint when it comes to analyzing the shadow MMU. Before the TDP MMU came along, i.e. when the shadow MMU was the only MMU, explicitly tracking the number of shadow pages wasn't as interesting, because the same information could more or less be gleaned from the pages_{1g,2m,4k} stats. But with the TDP MMU, where the shadow MMU is only used for nested TDP, it becomes extremely difficult, if not impossible, to determine which SPTEs are coming from the TDP MMU, and which are coming from the shadow MMU. E.g. when triaging/debugging shadow MMU performance issues due to "too many shadow pages", being able to observe that 99%+ of all shadow pages are unsync is critical to being able to deduce that KVM is effectively leaking shadow pages. Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20260612133727.411902-1-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24Merge tag 'kvm-s390-next-7.2-2' of ↵Paolo Bonzini
https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD * Fix S390_USER_OPEREXEC so it can now be enabled regardless of other unrelated capabilities * Fix handling of the _PAGE_UNUSED pte bit that could lead to guest memory corruption in some scenarios * A bunch of misc gmap fixes (locking, behaviour under memory pressure) * Fix CMMA dirty tracking
2026-06-24KVM: x86: Unconditionally recompute CR8 intercept on PPR updateCarlos López
The TPR_THRESHOLD field in the VMCS is used by VMX to induce VM exits when the guest's virtual TPR falls under the specified threshold, allowing KVM to inject previously masked interrupts. KVM handles these VM exits in handle_tpr_below_threshold(). Commit eb90f3417a0c ("KVM: vmx: speed up TPR below threshold vmexits") optimized this function by calling apic_update_ppr() instead of raising KVM_REQ_EVENT. apic_update_ppr() then raises KVM_REQ_EVENT if there is a pending, deliverable interrupt. However, if there are no new interrupts pending, apic_update_ppr() does not issue the request. Thus, kvm_lapic_update_cr8_intercept() and vmx_update_cr8_intercept() are not called before VM entry, which results in a high, stale TPR_THRESHOLD. This is problematic due to the following sentence in 28.2.1.1 "VM-Execution Control Fields" in the SDM: The following check is performed if the “use TPR shadow” VM-execution control is 1 and the “virtualize APIC accesses” and “virtual-interrupt delivery” VM-execution controls are both 0: the value of bits 3:0 of the TPR threshold VM-execution control field should not be greater than the value of bits 7:4 of VTPR. This error condition is typically not observed when KVM runs on a bare metal system because modern processors support APICv, which enables virtual-interrupt delivery, and which KVM uses when possible. This causes the processor to no longer generate TPR-below-threshold exits and to no longer check TPR_THRESHOLD on entry. However, when running on older platforms, or under nested virtualization on a hypervisor that does not support virtual-interrupt delivery and enforces this check (like Hyper-V) this can cause a VM entry failure with hardware error 0x7, as seen in [1]. Call kvm_lapic_update_cr8_intercept() if apic_update_ppr() does not find a deliverable interrupt (and thus does not raise KVM_REQ_EVENT). Remove calls to kvm_lapic_update_cr8_intercept() on paths that end up in apic_update_ppr(), as they now become redundant. This ensures that any path that updates the guest's PPR also figures out if KVM needs to wait for a TPR change (using TPR_THRESHOLD on VMX or CR8 intercepts on SVM). Link: https://github.com/coconut-svsm/svsm/issues/1081 [1] Tested-by: Stefano Garzarella <sgarzare@redhat.com> Cc: stable@vger.kernel.org Fixes: eb90f3417a0c ("KVM: vmx: speed up TPR below threshold vmexits") Signed-off-by: Carlos López <clopez@suse.de> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20260618174347.1981064-3-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest modeSean Christopherson
When updating CR8 intercepts, get vmcs12 if and only if the vCPU is in guest mode so that a future change can have update CR8 intercepts during vCPU creation, without running afoul of get_vmcs12()'s lockdep assertion. ------------[ cut here ]------------ debug_locks && !(lock_is_held(&(&vcpu->mutex)->dep_map) || !refcount_read(&vcpu->kvm->users_count)) WARNING: arch/x86/kvm/vmx/nested.h:61 at get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline], CPU#0: syz.2.19/5879 WARNING: arch/x86/kvm/vmx/nested.h:61 at vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879, CPU#0: syz.2.19/5879 Modules linked in: CPU: 0 UID: 0 PID: 5879 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline] RIP: 0010:vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879 Call Trace: <TASK> apic_update_ppr arch/x86/kvm/lapic.c:984 [inline] kvm_lapic_reset+0x1c24/0x2980 arch/x86/kvm/lapic.c:3023 kvm_vcpu_reset+0x44c/0x1bf0 arch/x86/kvm/x86.c:12986 kvm_arch_vcpu_create+0x746/0x8b0 arch/x86/kvm/x86.c:12847 kvm_vm_ioctl_create_vcpu+0x428/0x930 virt/kvm/kvm_main.c:4201 kvm_vm_ioctl+0x893/0xd50 virt/kvm/kvm_main.c:5159 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> No functional change intended. Reported-by: syzbot ci <syzbot+ci493c6d734b63e050@syzkaller.appspotmail.com> Closes: https://lore.kernel.org/all/6a2adf3b.3b0a2d4e.8c8d1.0012.GAE@google.com Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20260618174347.1981064-2-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: WARN (once) if RTC pending EOI tracking goes off the railsSean Christopherson
WARN once if KVM's tracking for pending EOIs for Real-Time Clock IRQs goes off the rails, as there's no reason to bug the host or risk a DoS due to spamming dmesg with endless WARNs. Absolute worst case scenario, guest time will go awry. Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Message-ID: <20260618174527.1982333-1-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: WARN and fail kvm_set_irq() if a PIC or I/O APIC vector is invalidSean Christopherson
WARN and return an error up the stack if the PIC or I/O APIC encounters an invalid vector when injecting an IRQ, as there is no danger to the host and thus no justification for potentially panicking the kernel. Don't bug the VM either, as the risk of corrupting the guest is minuscule, and the guest might even be completely tolerant of a lost interrupt. Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Message-ID: <20260618185213.2019937-1-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Bug the VM, not the kernel, if the ISR count {under,over}flowsSean Christopherson
Bug the VM, not the host kernel, if KVM's ISR count {under,over}flows when tracking in-flight ISRs. There is zero danger to the host if KVM messes up its IRQ tracking. Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Message-ID: <20260618185350.2020845-1-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86/mmu: Bug the VM, not the host kernel, if KVM write-protects upper SPTEsSean Christopherson
Instead of bugging the host kernel, WARN and terminate the VM if KVM attempts to write-protect at a level that cannot use leaf SPTEs. There is no reason to bring down the entire host; even termininating the VM is likely overkill, but in theory a missed write could corrupt guest memory, so play it safe. Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Message-ID: <20260618185641.2022368-1-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: x86: Replace BUG_ON() with WARN_ON_ONCE() on "bad" nested GPA translationSean Christopherson
If KVM attempts to translate what it thinks is an L2 GPA with a non-nested MMU, simply WARN and return the GPA, i.e. trust the MMU more than the caller, as there is zero reason to potentially panic the host kernel just because KVM misused an API. Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Message-ID: <20260618185746.2023283-1-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-06-24KVM: s390: Return failure in case of failure in kvm_s390_set_cmma_bits()Claudio Imbrenda
If the allocation of the bits array failed, kvm_s390_set_cmma_bits() would return 0 instead of an error code. Rework the function to use the __free() macros and thus simplify the code flow; when the above mentioned allocation fails, simply return -ENOMEM. Fixes: e38c884df921 ("KVM: s390: Switch to new gmap") Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260623153331.233784-10-imbrenda@linux.ibm.com>
2026-06-24KVM: s390: Fix cmma dirty trackingClaudio Imbrenda
It is possible that some guest memory areas have not been touched yet when starting migration mode, and thus have no ptes allocated. Only existing and allocated ptes should count toward the total of dirty cmma entries. When starting migration mode, enable the migration_mode flag immediately, so that any subsequent ESSA will trap in the host and cause cmma_dirty_pages to be increased as needed. Subsequently, set the cmma_d bit on all existing cmma-clean PGSTEs, increasing cmma_dirty_pages as needed. Skipping cmma-dirty pages prevents double counting. Conversely, when disabling migration mode, set cmma_dirty_pages to 0 and clear the cmma_d bit in all existing PGSTEs. The invariant is that when migration mode is off, no PGSTE has its cmma_d bit set, and cmma_dirty_pages is 0. kvm->slots_lock protects kvm_s390_vm_start_migration() and kvm_s390_vm_stop_migration() from each other and from kvm_s390_get_cmma_bits(). Also fix dat_get_cmma() to properly wrap around if the first attempt reached the end of guest memory without finding cmma-dirty pages. [ imbrenda: Moved kvm_s390_sync_request_broadcast() before gmap_set_cmma_all_dirty() ] Fixes: e38c884df921 ("KVM: s390: Switch to new gmap") Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260623153331.233784-8-imbrenda@linux.ibm.com>
2026-06-24KVM: s390: Fix locking in kvm_s390_set_mem_control()Claudio Imbrenda
Add the missing locking around dat_reset_cmma(). Fixes: e38c884df921 ("KVM: s390: Switch to new gmap") Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260623153331.233784-7-imbrenda@linux.ibm.com>
2026-06-24KVM: s390: Fix handle_{sske,pfmf} under memory pressureClaudio Imbrenda
Under heavy memory pressure, handle_sske() and handle_pfmf() might cause an endless loop if the mmu cache runs empty, the atomic allocations fail, and the top-up function also fails. While quite unlikely, that scenario is not impossible. Fix the issue by not ignoring the return value of kvm_s390_mmu_cache_topup(), and appropriately returning an error code in case of failure. Fixes: e38c884df921 ("KVM: s390: Switch to new gmap") Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260623153331.233784-6-imbrenda@linux.ibm.com>
2026-06-24KVM: s390: Fix code typo in gmap_protect_asce_top_level()Claudio Imbrenda
The correct length to pass to kvm_s390_get_guest_pages() is asce.tl + 1, not asce.dt + 1. It was a typo, which, due to fortuitous circumstances, did not cause bugs. It should nonetheless be fixed. Fixes: e5f98a6899bd ("KVM: s390: Add some helper functions needed for vSIE") Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260623153331.233784-5-imbrenda@linux.ibm.com>
2026-06-24KVM: s390: Do not set special large pages dirtyClaudio Imbrenda
Special pages / folios should not be set dirty. This also applies to large pages. Add a missing check in gmap_clear_young_crste() to prevent setting the large page dirty if it is a special page. Fixes: a2c17f9270cc ("KVM: s390: New gmap code") Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260623153331.233784-4-imbrenda@linux.ibm.com>
2026-06-24KVM: s390: Fix dat_peek_cmma() overflowClaudio Imbrenda
If userspace passes a start address that is out of bounds, _dat_walk_gfn_range() will fail with -EFAULT, but state.end will not be touched and will stay 0. This will cause *count to underflow and report a very high number, and the function will end up erroneously reporting success. Fix by only setting *count if the end address is not smaller than the starting address. This way invalid starting addresses will correctly return -EFAULT and *count will correctly indicate that no values have been returned. Fixes: 7b368470e1a4 ("KVM: s390: KVM page table management functions: CMMA") Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260623153331.233784-3-imbrenda@linux.ibm.com>
2026-06-24s390/mm: Fix handling of _PAGE_UNUSED pte bitClaudio Imbrenda
The _PAGE_UNUSED softbit should not really be lying around. Its sole purpose is to signal to try_to_unmap_one() and try_to_migrate_one() that the page can be discarded instead of being moved / swapped. KVM has no way to know why a page is being unmapped, so it sets the bit on userspace ptes corresponding to unused guest pages every time they get unmapped. KVM has no reasonable way to clear the bit once the page is in use again. While set_ptes() checks and clears the bit, other paths that set new ptes did not. This led to used pages being thrown out as if they were unused, causing guest corruption. Fix the issue by clearing the _PAGE_UNUSED bit for present ptes in set_pte(), i.e. whenever a present pte is getting set. The check in set_ptes() is then redundant and can be removed. Also fix gmap_helper_try_set_pte_unused() to only set the bit if the pte is present; the _PAGE_UNUSED bit is only defined for present ptes and thus should not be set for non-present ptes. Fixes: c98175b7917f ("KVM: s390: Add gmap_helper_set_unused()") Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260623153331.233784-2-imbrenda@linux.ibm.com>
2026-06-24KVM: s390: Fix S390_USER_OPEREXEC enablement without STFLE 74Eric Farman
The KVM_CAP_S390_USER_OPEREXEC capability allows operation exceptions to be forwarded to userspace. But the actual enablement at the hardware level occurs in kvm_arch_vcpu_postcreate(), and only if STFLE.74 or user_instr0 are enabled. The latter is associated with a separate capability (KVM_CAP_S390_USER_INSTR0), so the only way this happens for the USER_OPEREXEC capability is if STFLE.74 is enabled. KVM unconditionally enables this bit in kvm_arch_init_vm(), but the guest could disable it from the CPU model and thus ignore this capability. Add USER_OPEREXEC to the check in kvm_arch_vcpu_postcreate(), such that either capability would enable this type of exception. Fixes: 8e8678e740ec ("KVM: s390: Add capability that forwards operation exceptions") Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> [Fixed patch title, as recommended by frankja@linux.ibm.com] Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260507200836.3500368-2-farman@linux.ibm.com>
2026-06-23Merge tag 'x86-urgent-2026-06-23' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fix from Ingo Molnar: - Prevent NULL dereference on theoretical missing IO bitmap (Li RongQing) * tag 'x86-urgent-2026-06-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/ioperm: Prevent NULL dereference on theoretical missing IO bitmap
2026-06-23Merge branch 'pci/sysfs'Bjorn Helgaas
- Require CAP_SYS_ADMIN to write to sysfs 'resourceN_resize' attributes (Krzysztof Wilczyński) - Convert PCI resource files to static attributes to avoid races that cause 'duplicate filename' warnings and boot panics (Krzysztof Wilczyński) - Remove pci_create_sysfs_dev_files() and pci_remove_sysfs_dev_files(), which are obsolete after converting to static attributes (Krzysztof Wilczyński) - Add security_locked_down(LOCKDOWN_PCI_ACCESS) to alpha PCI resource mmap path to match the generic path (Krzysztof Wilczyński) - Convert sysfs 'legacy_io' and 'legacy_mem' to static attributes (Krzysztof Wilczyński) - Remove pci_create_legacy_files() and pci_sysfs_init(), which are obsolete after converting to static attributes (Krzysztof Wilczyński) - Expose sysfs 'resourceN_resize' attributes only on platforms with PCI mmap (Krzysztof Wilczyński) - Use kstrtobool() to parse the 'rom' attribute input to avoid the unexpected behavior of enabling the ROM when writing '0' with no trailing newline (Krzysztof Wilczyński) * pci/sysfs: PCI/sysfs: Use kstrtobool() to parse the ROM attribute input PCI/sysfs: Limit BAR resize attribute scope to platforms with PCI mmap PCI/sysfs: Remove pci_create_legacy_files() and pci_sysfs_init() PCI/sysfs: Convert legacy I/O and memory attributes to static definitions PCI/sysfs: Add __weak pci_legacy_has_sparse() helper alpha/PCI: Compute legacy size in pci_mmap_legacy_page_range() PCI: Add macros for legacy I/O and memory address space sizes PCI/sysfs: Remove pci_{create,remove}_sysfs_dev_files() alpha/PCI: Convert resource files to static attributes alpha/PCI: Add static PCI resource attribute macros alpha/PCI: Remove WARN from __pci_mmap_fits() and __legacy_mmap_fits() alpha/PCI: Fix __pci_mmap_fits() overflow for zero-length BARs alpha/PCI: Use PCI resource accessor macros alpha/PCI: Use BAR index in sysfs attr->private instead of resource pointer alpha/PCI: Add security_locked_down() check to pci_mmap_resource() PCI/sysfs: Limit pci_sysfs_init() late_initcall compile scope PCI/sysfs: Add stubs for pci_{create,remove}_sysfs_dev_files() PCI/sysfs: Warn about BAR resize failure in __resource_resize_store() PCI/sysfs: Convert PCI resource files to static attributes PCI/sysfs: Add static PCI resource attribute macros PCI/sysfs: Add CAP_SYS_ADMIN check to __resource_resize_store() PCI/sysfs: Split pci_llseek_resource() for device and legacy attributes PCI/sysfs: Only allow supported resource types in I/O and MMIO helpers PCI: Add pci_resource_is_io() and pci_resource_is_mem() helpers PCI/sysfs: Use PCI resource accessor macros
2026-06-23PCI/sysfs: Convert legacy I/O and memory attributes to static definitionsKrzysztof Wilczyński
Currently, legacy_io and legacy_mem are dynamically allocated and created by pci_create_legacy_files(), with pci_adjust_legacy_attr() updating the attributes at runtime on Alpha to rename them and shift the size for sparse addressing. Convert to four static const attributes (legacy_io, legacy_io_sparse, legacy_mem, legacy_mem_sparse) with .is_bin_visible() callbacks that use pci_legacy_has_sparse() to select the appropriate variant per bus. The sizes are compile-time constants and .size is set directly on each attribute. Register the groups in pcibus_groups[] under a HAVE_PCI_LEGACY guard so the driver model handles creation and removal automatically. Stub out pci_create_legacy_files() and pci_remove_legacy_files() as the dynamic creation is no longer needed. Remove the __weak pci_adjust_legacy_attr(), Alpha's override, and its declaration from both Alpha and PowerPC asm/pci.h headers. Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Link: https://patch.msgid.link/20260508043543.217179-23-kwilczynski@kernel.org
2026-06-23PCI/sysfs: Add __weak pci_legacy_has_sparse() helperKrzysztof Wilczyński
Currently, Alpha's sparse/dense legacy attribute handling is done via pci_adjust_legacy_attr(), which updates dynamically allocated attributes at runtime. The upcoming conversion to static attributes needs a way to determine sparse support at visibility check time. Add a __weak pci_legacy_has_sparse() that returns false by default. Alpha overrides it to check has_sparse() on the bus host controller. Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Link: https://patch.msgid.link/20260508043543.217179-22-kwilczynski@kernel.org
2026-06-23alpha/PCI: Compute legacy size in pci_mmap_legacy_page_range()Krzysztof Wilczyński
Currently, pci_mmap_legacy_page_range() reads the legacy resource size from bus->legacy_mem->size or bus->legacy_io->size. This couples the mmap bounds check to the struct pci_bus fields that will be removed when legacy attributes are converted to static definitions. Compute the size directly using PCI_LEGACY_MEM_SIZE (0x100000) and PCI_LEGACY_IO_SIZE (0xffff) macros, and shift by 5 bits for sparse systems. Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Magnus Lindholm <linmag7@gmail.com> Tested-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Acked-by: Magnus Lindholm <linmag7@gmail.com> Link: https://patch.msgid.link/20260508043543.217179-21-kwilczynski@kernel.org
2026-06-23alpha/PCI: Convert resource files to static attributesKrzysztof Wilczyński
Previously, Alpha's PCI resource files (resourceN, resourceN_sparse, resourceN_dense) were dynamically created by pci_create_resource_files(), which overrides the generic __weak implementation. The previous code allocated bin_attributes at runtime and managed them via the res_attr[] and res_attr_wc[] fields in struct pci_dev. Convert to static const attributes with three attribute groups (plain, sparse, dense), each with an .is_bin_visible() callback that checks resource length, has_sparse(), and sparse_mem_mmap_fits(). A .bin_size() callback provides the resource size to the kernfs node, with the sparse variant shifting by 5 bits for byte-level addressing. Register the groups via ARCH_PCI_DEV_GROUPS so the driver model handles creation and removal automatically. Use the new pci_resource_is_mem() helper for the type check, replacing the open-coded bitwise flag test. Finally, remove pci_create_resource_files(), pci_remove_resource_files(), pci_create_attr(), and pci_create_one_attr() which are no longer needed. Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Magnus Lindholm <linmag7@gmail.com> Tested-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Acked-by: Magnus Lindholm <linmag7@gmail.com> Link: https://patch.msgid.link/20260508043543.217179-18-kwilczynski@kernel.org
2026-06-23alpha/PCI: Add static PCI resource attribute macrosKrzysztof Wilczyński
Add macros for declaring static binary attributes for Alpha's PCI resource files: - pci_dev_resource_attr(), for dense/BWX systems (mmap dense) - pci_dev_resource_sparse_attr(), for sparse systems (mmap sparse) - pci_dev_resource_dense_attr(), for dense companion files (mmap dense) Each macro creates a const bin_attribute with the BAR index stored in the .private property and the appropriate .mmap() callback. Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Magnus Lindholm <linmag7@gmail.com> Tested-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Acked-by: Magnus Lindholm <linmag7@gmail.com> Link: https://patch.msgid.link/20260508043543.217179-17-kwilczynski@kernel.org