| #
67f8bc84 |
| 01-Sep-2026 |
Maxime Ripard <mripard@kernel.org> |
Merge drm/drm-fixes into drm-misc-fixes
Let's start the 7.3 drm-misc-fixes cycle.
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
Revision tags: v7.3-rc1 |
|
| #
7bb6284a |
| 25-Aug-2026 |
Linus Torvalds <torvalds@linux-foundation.org> |
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm updates from Paolo Bonzini: "ARM64:
- Add support for 'slot' based PMU events, paired with new UAPI that compels
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm updates from Paolo Bonzini: "ARM64:
- Add support for 'slot' based PMU events, paired with new UAPI that compels the user to select a specific PMU implementation
- Lazy save/restore of vCPU state for pKVM, along with various fixes and cleanups to the management of vCPU state between the untrusted host and pKVM hypervisor
- Disable traps of EL1 registers for nested hypervisors when FEAT_NV2p1 is present, guaranteeing that EL2-specific register bits are stateful in the EL1 counterpart
- Leverage FEAT_NV3 to avoid unnecessary ERET/TLBI traps when the scope of those instructions remains 'in host' (i.e. L1 kernel/userspace)
- Pile of fixes for the management of the VNCR pseudo-TLB, such as under-invalidations and races with concurrent TLBIs on other vCPUs
- Consolidate the non-protected and pKVM view of ICH_VTR_EL2 to a runtime-patched constant, allowing the same data to be shared with pKVM prior to dropping host privileges
- Considerable pile of LLM-assisted fixes around the shop but mostly in the VGIC, our in-kernel generator of bugs (and sometimes interrupts)
LoongArch:
- Advertise already-supported capabilities
- Some bug fixes about timer and MMIO
- Some hardening about interrupt injection
- Replace kvm_err() with kvm_pr_unimpl()
- Add FPU/LSX/LASX test cases for selftests
RISC-V:
- Svadu/Zicfiss/Zicfilp FWFT support for Guest
- Use try_cmpxchg for IMSIC MRIF RMW
- More arch-specific tracepoints in KVM RISC-V
- Eager page splitting when enabling dirty logging
- Optimize hfence request handling for SMP Guests
- Improve dirty log clearing by skipping zero bits in mask
- Guard HFENCE range loops against overflow
- CPU PM notifiers in KVM RISC-V for non-retentive idle states
- Fix kernel-mode vector context save/restore for Guest
s390:
- Fixes for vfio-ap
- Fixes for the gmap rework
- Fixes for vsie
- AI triggered fixes all over
- diag9c tracing
- code move preparation for the additional arm64 support
- enable CONTEXT_ANALYSIS
x86:
- Perform spring cleaning on x86.{c,h} and asm/kvm_host.h, by adding regs.c (the kvm_cache_regs.h => regs.h is already applied) and msrs.{c,h}, and moving relevant code out of x86.c
- Split kvm_mmu in three parts, respectively to describe the format of page tables, walking the guest page tables and building the page tables. Always use the same page table walker kvm->arch.gva_walk as the entry point to convert a guest's virtual address, where the previous code used two different kvm_mmu structs depending on whether the walk included nested EPT/NPT or not. Make page fault vmexits reuse the permission checking machinery that is used for guest page faults. This is both a cleanup and a baby step towards supporting XS/XU memory permissions
- Document some of the "fun" gotchas with the APIC base when creating IRQCHIPs on x86
- Remove a defunct masterclock update from kvm_xen_shared_info_init(). It could result in incorrect kvmclock due to triggering an unnecessary switch to/from masterclock mode
- Skip Xen runstate time updates if time has effectively gone backwards, so that the guest doesn't report 100% steal time for a very, very long time
- Drop KVM's runtime updates of the Xen PV timing CPUID leaf, as KVM was updating the wrong sub-leaf, and upstream KVM will soon provide all the information needed by userspace to populate the CPUID field itself
- Fix a bug where KVM would walk a newly created rmap without holding the rmap lock (or mmu_lock) during aging
- Fix a bug where aging TDP MMU SPTEs could clobber FROZEN SPTEs
- Fix a variety of #DB priority bugs
- Fix a class of races related to enabling Hyper-V emulation on a vCPU after the vCPU is visible to the rest of KVM
- Use static calls for nested virtualization ops
- Move more KVM-internal code out of x86's kvm_host.h
- Enumerate support for a variety of Zhaoxin instructions that don't require explicit virtualization
- Fix missing EFER validation bugs, including in the KVM_SET_SREGS* path
- Harden kvm_vcpu_map() against double-mapping and thus leaking references
- Misc fixes and cleanups, e.g. for largely benign syzkaller splats
x86 (Intel):
- Zero a vCPU's entry in VMX's Posted Interrupt Descriptor table used for IPI virtualization when the vCPU is freed, to fix a use-after-free where hardware will write to a freed vCPU's PID
- Service local TLB flushes on a failed nested VM-Enter to fix a bug where KVM could miss a TLB on a future, successful VM-Enter with the same L2 VPID
- Cap the maximum value shoved into the VMX Preemption Timer to workaround an erratum that affects all existing Intel CPUs that support CPUID 0x15
- Fix VPID virtualization bugs where KVM would fail to flush hardware TLBs
- Harden the TDX "populate" ioctls against bad input, and to prepare for supporting in-place private<=>shared conversion
x86 (AMD):
- Forcefully invalidate SNP VMSA pages if their backing guest_memfd page is zapped/invalidated, e.g. due to a PUNCH_HOLE in response to a Page-State Change request
- Remove a dying VM from the GA Log notifier list before the VM is actually destroyed, to fix a potential use-after-free
- While FOLL_WRITE was needed in the past to trigger CoW unsharing, nowadays FOLL_LONGTERM does that already even without FOLL_WRITE, and in fact, get_user_pages() actually disallows FOLL_WRITE together with FOLL_LONGTERM. So don't pass FOLL_WRITE when registering encrypted memory regions, i.e. when pinning SEV/SEV-ES guest memory, to fix a regression with file-backed memory introduced by KVM's (correct) usage of long-term pins
(This was reviewed by mm maintainers; for more information, see commit ee1a586dd1fa "KVM: SEV: Drop FOLL_WRITE for encrypted region registration")
- Allocate full pages for SEV/SEV-ES {DE,EN}CRYPT ops on SNP-enabled hosts to fix a data corruption issue due to the PSP driver assigning to-be-written pages to firmware (as required by the SNP specs)
- Unconditionally intercept ICBEP so that KVM generates the correct guest RIP when handling an ICEBP-induced TASK_SWITCH #VMEXIT
- Harden the SNP "populate" ioctls against bad input, and to prepare for supporting in-place private<=>shared conversion
Generic:
- Remove kvm_debugfs_dir if kvm_init() fails after creating KVM's debugfs
- Add a per-VM bitmap to track which vCPU IDs have been "claimed" but for which the vCPU isn't yet online, and use the bitmap to reject duplicate IDs before calling into arch code. This allows arch code to consume vcpu_id without having to worry about cross-vCPU clobbering (at least s390 and x86 have had related bugs)
- Rework the so called "prepare" and "invalidate" guest_memfd hooks to prepare for in-place private<=>shared conversion, and clean up a few warts along the way
Selftests:
- Automatically allocate a full page for L2 guest stacks on x86 instead of requiring test-specific L1 guest code to carve out a portion of the L1 stack for L2 usage, and to ensure the L2 stack also adheres to the x86-64 calling convention ABI
- Add a selftest to verify {Guest,Host}-Only behavior in x86's mediated PMU
- Clean up nested SVM's handling of GPRs on L2<=>L1 transitions, reuse the functionality for nested VMX, and drop the ucall hack that was fudging around the lack of GPR switching on nVMX
- Add a stress test to verify KVM doesn't clobber/drop #PF state, e.g. CR2, across save/restore, including when L2 is active
- Add a test to verify KVM_CREATE_VM accepts exactly what is reported by KVM_CAP_VM_TYPES
- Misc selftests fixes and cleanups
- Fix several issues with seeding the pRNG, and rework the pRNG APIs to that the pRNG can be sanely used in host code, not just guest code
- Add an IRQ test to validate virtual IRQ deliverty for IRQs wired up via KVM_IRQFD + KVM_SET_GSI_ROUTING, with optional support for triggering IRQs via writes to an assigned VFIO device
- Add syscall wrappers to assert success on a variety of pthreads and CPU affinity APIs
- Set vCPU pthread affinity as early as possible to reduce contention issues that were surfaced by PREEMPT_LAZY, which result in runtimes of over a minute on large hosts, versus the expected ~5 seconds
- Rework the PMU counters test to run each testcase using a single VM with many vCPUs for each sub-testcase, instead of using a unique VM for each sub-testcase. This cuts the runtime by ~20x
Miscellaneous:
- MAINTAINERS updates for vfio-ap, guest_memfd, kvm-x86. Mostly representing the status quo more accurately, but also... welcome David Hildenbrand as guest_memfd reviewer!"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (413 commits) KVM: arm64: Validate GICv5 timer PPIs before claiming ownership KVM: arm64: vgic: Reject out-of-range GICv5 PPI IDs KVM: arm64: vgic: Prevent speculative SPI array underflow KVM: arm64: vgic: Free gic_kvm_info on initialization failure KVM: arm64: Avoid mismatched accesses to 'struct kvm_nvhe_init_params' s390/vfio-ap: Fix NULL deref in status_show() during queue probe s390/vfio-ap: Fix hot-unplug skipped when last AP adapter or domain removed s390/vfio-ap: fix potential use of uninitialized apm_filtered bitmap s390/vfio-ap: Fix control domain removal in vfio_ap_mdev_cfg_remove s390/vfio-ap: Fix required lock not held during update of ap_matrix_mdev object s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL s390/vfio-ap: Fix stale do_remove flag across iterations in vfio_ap_mdev_cfg_remove RISC-V: KVM: fix vcpu vector context handling for kernel-mode vector riscv: vector: allow non-preemptible kernel-mode vector with IRQs off riscv: vector: refactor riscv_v_start_kernel_context KVM: s390: gmap: Make prefix handling optional KVM: s390: gmap: Make CMMA optional KVM: s390: gmap: Make storage keys optional KVM: s390: Prepare gmap for a second KVM implementation ...
show more ...
|
| #
d75b4846 |
| 18-Aug-2026 |
Paolo Bonzini <pbonzini@redhat.com> |
Merge tag 'kvm-x86-misc-7.3' of https://github.com/kvm-x86/linux into HEAD
KVM x86 misc changes for 7.3
- Fix VPID virtualization bugs where KVM would fail to flush hardware TLBs.
- Harden the S
Merge tag 'kvm-x86-misc-7.3' of https://github.com/kvm-x86/linux into HEAD
KVM x86 misc changes for 7.3
- Fix VPID virtualization bugs where KVM would fail to flush hardware TLBs.
- Harden the SNP and TDX "populate" ioctls against bad input, and to prepare for supporting in-place private<=>shared conversion.
- Fix a variety of #DB priority bugs.
- Fix a class of races related to enabling Hyper-V emulation on a vCPU after the vCPU is visible to the rest of KVM.
- Use static calls for nested virtualization ops.
- Move more KVM-internal code out of x86's kvm_host.h.
- Enumerate support for a variety of Zhaoxin instructions that don't require explicit virtualization.
- Fix missing EFER validation bugs, including in the KVM_SET_SREGS* path.
- Harden kvm_vcpu_map() against double-mapping and thus leaking references.
- Misc fixes and cleanups, e.g. for largely benign syzkaller splats.
show more ...
|
|
Revision tags: v7.2, v7.2-rc7, v7.2-rc6, v7.2-rc5, v7.2-rc4 |
|
| #
184bd464 |
| 13-Jul-2026 |
Yosry Ahmed <yosry@kernel.org> |
KVM: x86: Check EFER validity on KVM_SET_SREGS*
When handling userspace SREGS writes, check the validity of EFER (i.e. allowed bits) before writing the new value of EFER through the per-vendor set_e
KVM: x86: Check EFER validity on KVM_SET_SREGS*
When handling userspace SREGS writes, check the validity of EFER (i.e. allowed bits) before writing the new value of EFER through the per-vendor set_efer callbacks. This prevents userspace from writing bogus values (e.g. EFER.SVME=1 with nested=0).
Note: on KVM_SET_MSRS, KVM only checks EFER validity in terms of KVM caps, not guest caps, so it is possible to set EFER bits that are supported by KVM but not by the guest CPUID. Potentially allowing userspace to set msrs before CPUID.
However, for KVM_SET_SREGS*, check the validity of the set bits against both KVM and guest caps. This is consistent with other validity checks (e.g. for CR4) that check validity against guest caps, which already imposes the need to set CPUID before SREGS.
Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260713180153.2728382-2-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com>
show more ...
|
|
Revision tags: v7.2-rc3, v7.2-rc2, v7.2-rc1 |
|
| #
a204badd |
| 24-Jun-2026 |
Paolo Bonzini <pbonzini@redhat.com> |
Merge branch 'kvm-chainsaw' into HEAD
The kvm_mmu is a "god data structure" that includes three different tasks: describing the guest page table's format, walking the guest page tables and building
Merge branch 'kvm-chainsaw' into HEAD
The kvm_mmu is a "god data structure" that includes three different tasks: describing the guest page table's format, walking the guest page tables and building the page tables. This means that the (already poorly named) nested_mmu is only used in part, since it has no page tables to construct.
Furthermore, some parts are reused across guest and host page tables (such as the reserved bits detector) but others are not; for example permission_fault is replaced by simplified code such as is_executable_pte().
This series cleans this up by splitting kvm_mmu in three parts:
- kvm_pagewalk is the page table walker. There are two of them per vCPU, gva_walk and ngpa_walk. walk_mmu is *always* replaced by a single gva_walk no matter if running an L1 or L2 guest, unlike in the current code that moves it between root_mmu and nested_mmu.
- kvm_mmu retains the page table building functionality. It uses a page table walker to build shadow pages; that is always gva_walk for root_mmu or ngpa_walk for guest_mmu.
- kvm_page_format allows KVM to operate on PTEs that already exist, and merges the code around permission_mask() with the pre-existing struct rsvd_bits_validate. Both kvm_pagewalk and kvm_mmu have their own kvm_page_format, just like struct kvm_mmu had two instances of struct rsvd_bits_validate for gPTE and SPTE reserved bit checks.
The cleanup alone already does something useful, which is to reduce the confusion between guest_mmu and nested_mmu. nested_mmu came to exist long before the introduction of guest_mmu and stole the obvious name, resulting in comments like "Exempt nested MMUs" where the code actually exempts guest_mmu. Renaming guest_mmu could be the next step, though the RFC had multiple opinions about how to do this.
However, the last patch also shows the code reuse benefits can be used for new features too. By adapting the permission_fault() machinery and using it to test SPTEs against struct kvm_page_fault, it makes it possible to support SPTEs that have XS!=XU; these were not supported yet by KVM, but could now be added via memory attributes.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
|
Revision tags: v7.1, v7.1-rc7, v7.1-rc6, v7.1-rc5, v7.1-rc4 |
|
| #
148fe965 |
| 11-May-2026 |
Paolo Bonzini <pbonzini@redhat.com> |
KVM: x86/mmu: unify root_gva_walk and ngva_walk
At this point, vcpu->arch.ngva_walk and vcpu->arch.root_gva_walk contain the same information; compare init_kvm_page_walk() on one side with init_kvm_
KVM: x86/mmu: unify root_gva_walk and ngva_walk
At this point, vcpu->arch.ngva_walk and vcpu->arch.root_gva_walk contain the same information; compare init_kvm_page_walk() on one side with init_kvm_softmmu() + shadow_mmu_init_context() on the other. They only differ in when each is active, and root_gva_walk is also used by shadow paging, via FNAME(walk_addr) and its callers.
Always use the same instance of kvm_pagewalk to do GVA->GPA translations, for both guest emulation and shadow paging, instead of flipping the gva_walk pointer back and forth. After all the page walking does behave the same no matter if you are in guest mode or not; the difference lies in the behavior of kvm_translate_gpa and thus in vcpu->arch.mmu, not in the page walker itself.
This completes the transition from walk_mmu/nested_mmu as the page walking entry points to gva_walk/ngpa_walk, and removes duplicated code between the initialization of root_mmu.w and ngva_walk (The Struct Formerly Known As nested_mmu).
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
| #
d42e93ee |
| 11-May-2026 |
Paolo Bonzini <pbonzini@redhat.com> |
KVM: x86/mmu: change walk_mmu to struct kvm_pagewalk
Now that walk_mmu is only accessed for its "w" member, store directly the pointer to it. Since it is only used to convert guest GVAs or nGVAs, c
KVM: x86/mmu: change walk_mmu to struct kvm_pagewalk
Now that walk_mmu is only accessed for its "w" member, store directly the pointer to it. Since it is only used to convert guest GVAs or nGVAs, call it gva_walk.
Note that there is still one container_of() going from (possibly) walk_mmu.w to its containing struct kvm_mmu, but for now all instances of struct kvm_pagewalk do live within a kvm_mmu.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
|
Revision tags: v7.1-rc3 |
|
| #
ac889bdd |
| 10-May-2026 |
Paolo Bonzini <pbonzini@redhat.com> |
KVM: x86/mmu: introduce struct kvm_pagewalk
In preparation for separating walking and building of page tables, introduce a dummy struct kvm_pagewalk and pass it around instead of its containing kvm_
KVM: x86/mmu: introduce struct kvm_pagewalk
In preparation for separating walking and building of page tables, introduce a dummy struct kvm_pagewalk and pass it around instead of its containing kvm_mmu to functions that do not build the page tables. Outermost functions retrieve the mmu via container_of, while internal functions can pass around the struct kvm_pagewalk pointer.
x86.c is still mostly oblivious to the existence of struct kvm_pagewalk, with are only a couple exceptions for now, but the plan is for it to use struct kvm_pagewalk whenever dealing with guest page tables and have only limited knowledge of struct kvm_mmu.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
| #
458dbb64 |
| 24-Jun-2026 |
Paolo Bonzini <pbonzini@redhat.com> |
Merge branch 'kvm-spring-clean' into HEAD
It's still technically spring!
Perform spring cleaning on x86.{c,h} and asm/kvm_host.h, by adding regs.c (the kvm_cache_regs.h => regs.h is already applied
Merge branch 'kvm-spring-clean' into HEAD
It's still technically spring!
Perform spring cleaning on x86.{c,h} and asm/kvm_host.h, by adding regs.c (the kvm_cache_regs.h => regs.h is already applied) and msrs.{c,h}, and moving relevant code out of x86.c.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
| #
2f5bb3fe |
| 13-Jun-2026 |
Sean Christopherson <seanjc@google.com> |
KVM: x86: Move the bulk of register specific code from x86.c to regs.c
Introduce regs.c, and move the vast majority of register specific code out of x86.c and into regs.c. Deliberately leave behind
KVM: x86: Move the bulk of register specific code from x86.c to regs.c
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>
show more ...
|