mirror of
https://github.com/torvalds/linux.git
synced 2026-10-17 06:20:02 +02:00
master
7 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Linus Torvalds
|
7bb6284aa7 |
Arm:
* 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
|
||
|
Yosry Ahmed
|
92b2af2b6d |
KVM: x86: Move supported EFER bits to kvm_caps
Supported EFER bits naturally fits into kvm_caps because it gets recomputed during vendor initialization (e.g. to account for EFER.SVME being allowed/disallowed based on nested being enabled/disabled). Move efer_supported_bits into kvm_caps as supported_efer_bits (for naming consistency). As the bitmask is now globally visible as part of kvm_caps, there's little use for helpers to enable/disable specific bits, so drop them and open-code updates to kvm_caps.supported_efer_bits. No functional change intended. Suggested-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Nikolay Borisov <nik.borisov@suse.com> Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260713181020.2735367-6-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> |
||
|
Yosry Ahmed
|
37352c4fbd |
KVM: x86: Reverse the polarity of efer_reserved_bits
In preparation for moving efer_reserved_bits into kvm_caps, reverse its polarity and make it efer_supported_bits, to be more consistent with other fields in kvm_caps. No functional change intended. Reviewed-by: Nikolay Borisov <nik.borisov@suse.com> Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260713181020.2735367-5-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> |
||
|
Yosry Ahmed
|
a4b8acd428 |
KVM: x86: Always initialize EFER reserved bits on vendor initialization
EFER reserved bits are statically initialized, and do not reset if a vendor module is re-loaded. For example, loading kvm_amd with nested=1 removes EFER.SVME (and potentially EFER.LMSLE) from the reserved bits. Reloading kvm_amd with nested=0 does not add them back, allowing userspace to set EFER.SVME with nested=0. Re-initializing EFER reserved bits before configuring them on vendor initialization. Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260713181020.2735367-4-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> |
||
|
Yosry Ahmed
|
e62392bf39 |
KVM: x86: Disallow EFER.LME and EFER.LMA if long mode is not supported
Remove EFER.LME and EFER.LMA from EFER reserved bits only if long mode is actually supported. KVM does check long-mode support before allowing the bits for guest writes and userspace writes through KVM_SET_SREGS* (in __kvm_valid_efer()), but userspace writes through KVM_SET_MSRS only check reserved bits. In practice, this doesn't really matter. The true motiviation is getting rid of the #ifdeffery when initializing efer_reserved_bits. Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260713181020.2735367-3-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> |
||
|
Sean Christopherson
|
765ae5dc6f |
KVM: x86: Move "struct kvm_x86_msr_filter" definition to msrs.c
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> |
||
|
Sean Christopherson
|
7a26830801 |
KVM: x86: Move the bulk of MSR specific code from x86.c to msrs.{c,h}
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>
|