mirror of
https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10.git
synced 2026-09-09 00:07:04 +08:00
main
100
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Maxim Levitsky
|
7281a972ae |
KVM: selftests: access_tracking_perf_test: bump number of NUMA nodes to 32
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 4a0dcc6a15f94de3dee90bf52234d330cc3aad4e Author: Maxim Levitsky <mlevitsk@redhat.com> Date: Fri Jun 12 11:00:38 2026 -0400 KVM: selftests: access_tracking_perf_test: bump number of NUMA nodes to 32 It's rare to find a system that has more than 4 sockets, but a system can have more than 4 NUMA nodes if each socket exposes its chiplets as separate NUMA nodes. In particular, our CI caught a failure in this test on a system with two sockets, each containing an 'AMD EPYC 7601 32-Core Processor'. Bump the limit to 32, just in case. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Message-ID: <20260612150038.1277394-1-mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
a4444fcb2f |
KVM: x86: Rate-limit global clock updates on vCPU load
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 8fe2e698fce4a95a3ac2c25fe59832a3c22534c6 Author: Lei Chen <lei.chen@smartx.com> Date: Thu Apr 9 22:22:26 2026 +0800 KVM: x86: Rate-limit global clock updates on vCPU load 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> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
332f7de796 |
KVM: x86: Fix ERAPS RAP clear on INVPCID single-context invalidation
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit b60621c5121c9435eda99af7dc2100f5c0f88695 Author: Emily Ehlert <ehemily@amazon.de> Date: Mon May 18 13:59:56 2026 +0000 KVM: x86: Fix ERAPS RAP clear on INVPCID single-context invalidation Use kvm_register_mark_dirty() instead of kvm_register_is_dirty() to actually mark VCPU_EXREG_ERAPS as dirty when emulating INVPCID_TYPE_SINGLE_CTXT. kvm_register_is_dirty() is a read-only predicate whose return value is discarded, making the call a no-op. Without this fix, a single-context INVPCID will not trigger a RAP clear on the next VMRUN, breaking the ERAPS security guarantee. Fixes: db5e82496492 ("KVM: SVM: Virtualize and advertise support for ERAPS") Signed-off-by: Emily Ehlert <ehemily@amazon.de> Link: https://patch.msgid.link/20260518135956.82569-1-ehemily@amazon.de Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
956d0d76af |
KVM: x86: Swap the dst and src operand for MOVNTDQA
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 3098c076c83ea2913245cb915cdcba98eb24214c Author: Sean Christopherson <seanjc@google.com> Date: Wed May 6 14:35:14 2026 -0700 KVM: x86: Swap the dst and src operand for MOVNTDQA 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> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
23fa9eda53 |
KVM: selftests: Ensure gmem file sizes are multiple of host page size
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 87c810160ed738cd983e4a65ebe9709927c702c9 Author: Sean Christopherson <seanjc@google.com> Date: Tue May 12 08:56:34 2026 -0700 KVM: selftests: Ensure gmem file sizes are multiple of host page size When creating a guest_memfd file and associated memslot to validate shared guest memory, size the file+memslot to the maximum of the host or guest page size. Attempting to allocate a single guest page will fail if the host page size is greater than the guest page size, as KVM requires that the size of memslots and guest_memfd files are a multiple of the host page size. For simplicity, verify the entire file can be shared between guest and host, e.g. instead of trying to validate "partial" mappings. Fixes: 42188667be38 ("KVM: selftests: Add guest_memfd testcase to fault-in on !mmap()'d memory") Reported-by: Zenghui Yu <zenghui.yu@linux.dev> Closes: https://lore.kernel.org/all/0064952b-048c-455d-ad89-e27e5cb82591@linux.dev Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20260512155634.772602-1-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
91aecf3b4c |
KVM: selftests: Fix reserved value WRMSR testcase for multi-feature MSRs
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 9396cc1e282a280bcba2e932e03994e0aada4cd8 Author: Sean Christopherson <seanjc@google.com> Date: Thu Feb 12 18:38:41 2026 +0800 KVM: selftests: Fix reserved value WRMSR testcase for multi-feature MSRs When determining whether or not a WRMSR with reserved bits will #GP or succeed due to the WRMSR not existing per the guest virtual CPU model, expect failure if and only if _all_ features associated with the MSR are unsupported. Checking only the primary feature results in false failures when running on AMD and Hygon CPUs with only one of RDPID or RDTSCP, as AMD/Hygon CPUs ignore MSR_TSC_AUX[63:32], i.e. don't treat the bits as reserved, and so #GP only if the MSR is unsupported. Fixes: 9c38ddb3df94 ("KVM: selftests: Add an MSR test to exercise guest/host and read/write") Reported-by: Zhiquan Li <zhiquan_li@163.com> Closes: https://lore.kernel.org/all/20260209041305.64906-6-zhiquan_li@163.com Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260212103841.171459-5-zhiquan_li@163.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
b51a02ed55 |
KVM: x86: Use __DECLARE_FLEX_ARRAY() for UAPI structures with VLAs
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 2619da73bb2f10d88f7e1087125c40144fdf0987 Author: David Woodhouse <dwmw@amazon.co.uk> Date: Thu Mar 5 20:49:55 2026 +0100 KVM: x86: Use __DECLARE_FLEX_ARRAY() for UAPI structures with VLAs Commit |
||
|
Maxim Levitsky
|
9af13e5b5e |
KVM: selftests: Verify SEV+ guests can read and write EFER, CR0, CR4, and CR8
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit d2ea4ff1ce50787a98a3900b3fb1636f3620b7cf Author: Sean Christopherson <seanjc@google.com> Date: Tue Mar 10 14:18:41 2026 -0700 KVM: selftests: Verify SEV+ guests can read and write EFER, CR0, CR4, and CR8 Add "do no harm" testing of EFER, CR0, CR4, and CR8 for SEV+ guests to verify that the guest can read and write the registers, without hitting e.g. a #VC on SEV-ES guests due to KVM incorrectly trying to intercept a register. Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20260310211841.2552361-3-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
ba4d1330ae |
Documentation: kvm: fix formatting of the quirks table
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit dca01b0a264642929732c4db4a07e7b213304c15 Author: Paolo Bonzini <pbonzini@redhat.com> Date: Wed Mar 11 19:16:52 2026 +0100 Documentation: kvm: fix formatting of the quirks table A recently added quirk does not fit in the left column of the table, so it all has to be reformatted and realigned. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
b210db2de8 |
KVM: x86: clarify leave_smm() return value
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 6b1ca262a943a3307ee905faac0f4ff61ec3d656 Author: Paolo Bonzini <pbonzini@redhat.com> Date: Tue Mar 10 20:33:39 2026 +0100 KVM: x86: clarify leave_smm() return value The return value of vmx_leave_smm() is unrelated from that of nested_vmx_enter_non_root_mode(). Check explicitly for success (which happens to be 0) and return 1 just like everywhere else in vmx_leave_smm(). Likewise, in svm_leave_smm() return 0/1 instead of the 0/1/-errno returned by tenter_svm_guest_mode(). Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
266a857ac4 |
selftests: kvm: add a test that VMX validates controls on RSM
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 3e745694b032b405ff1ced74a8b3b95cdd00a385 Author: Paolo Bonzini <pbonzini@redhat.com> Date: Mon Mar 9 13:44:40 2026 +0100 selftests: kvm: add a test that VMX validates controls on RSM Add a test checking that invalid eVMCS contents are validated after an RSM instruction is emulated. The failure mode is simply that the RSM succeeds, because KVM virtualizes NMIs anyway while running L2; the two pin-based execution controls used by the test are entirely handled by KVM and not by the processor. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
2ea202fde6 |
selftests: kvm: extract common functionality out of smm_test.c
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit c52b534f26574ddf2f67cf07992ae2c25e8932c8 Author: Paolo Bonzini <pbonzini@redhat.com> Date: Mon Mar 9 13:43:57 2026 +0100 selftests: kvm: extract common functionality out of smm_test.c Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
2647619e27 |
KVM: SVM: check validity of VMCB controls when returning from SMM
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit be5fa8737d42c5ba16d2ea72c23681f8abbb07e8 Author: Paolo Bonzini <pbonzini@redhat.com> Date: Mon Mar 9 12:40:52 2026 +0100 KVM: SVM: check validity of VMCB controls when returning from SMM The VMCB12 is stored in guest memory and can be mangled while in SMM; it is then reloaded by svm_leave_smm(), but it is not checked again for validity. Move the cached vmcb12 control and save consistency checks out of svm_set_nested_state() and into a helper, and reuse it in svm_leave_smm(). Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
979fd3aac2 |
KVM: VMX: check validity of VMCS controls when returning from SMM
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 5a30e8aea079b3e4e79d6ce7a878f5f42efe9d0b Author: Paolo Bonzini <pbonzini@redhat.com> Date: Mon Mar 9 12:40:40 2026 +0100 KVM: VMX: check validity of VMCS controls when returning from SMM The VMCS12 is not available while in SMM. However, it can be overwritten if userspace manages to trigger copy_enlightened_to_vmcs12() - for example via KVM_GET_NESTED_STATE. Because of this, the VMCS12 has to be checked for validity before it is used to generate the VMCS02. Move the check code out of vmx_set_nested_state() (the other "not a VMLAUNCH/VMRESUME" path that emulates a nested vmentry) and reuse it in vmx_leave_smm(). Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
f381f24a5f |
KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated
JIRA: https://issues.redhat.com/browse/RHEL-151869
commit 87d0f901a9bd8ae6be57249c737f20ac0cace93d
Author: Sean Christopherson <seanjc@google.com>
Date: Tue Feb 3 11:07:10 2026 -0800
KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated
Explicitly set/clear CR8 write interception when AVIC is (de)activated to
fix a bug where KVM leaves the interception enabled after AVIC is
activated. E.g. if KVM emulates INIT=>WFS while AVIC is deactivated, CR8
will remain intercepted in perpetuity.
On its own, the dangling CR8 intercept is "just" a performance issue, but
combined with the TPR sync bug fixed by commit d02e48830e3f ("KVM: SVM:
Sync TPR from LAPIC into VMCB::V_TPR even if AVIC is active"), the danging
intercept is fatal to Windows guests as the TPR seen by hardware gets
wildly out of sync with reality.
Note, VMX isn't affected by the bug as TPR_THRESHOLD is explicitly ignored
when Virtual Interrupt Delivery is enabled, i.e. when APICv is active in
KVM's world. I.e. there's no need to trigger update_cr8_intercept(), this
is firmly an SVM implementation flaw/detail.
WARN if KVM gets a CR8 write #VMEXIT while AVIC is active, as KVM should
never enter the guest with AVIC enabled and CR8 writes intercepted.
Fixes:
|
||
|
Maxim Levitsky
|
49b87ae130 |
KVM: SVM: Initialize AVIC VMCB fields if AVIC is enabled with in-kernel APIC
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 3989a6d036c8ec82c0de3614bed23a1dacd45de5 Author: Sean Christopherson <seanjc@google.com> Date: Tue Feb 3 11:07:09 2026 -0800 KVM: SVM: Initialize AVIC VMCB fields if AVIC is enabled with in-kernel APIC Initialize all per-vCPU AVIC control fields in the VMCB if AVIC is enabled in KVM and the VM has an in-kernel local APIC, i.e. if it's _possible_ the vCPU could activate AVIC at any point in its lifecycle. Configuring the VMCB if and only if AVIC is active "works" purely because of optimizations in kvm_create_lapic() to speculatively set apicv_active if AVIC is enabled *and* to defer updates until the first KVM_RUN. In quotes because KVM likely won't do the right thing if kvm_apicv_activated() is false, i.e. if a vCPU is created while APICv is inhibited at the VM level for whatever reason. E.g. if the inhibit is *removed* before KVM_REQ_APICV_UPDATE is handled in KVM_RUN, then __kvm_vcpu_update_apicv() will elide calls to vendor code due to seeing "apicv_active == activate". Cleaning up the initialization code will also allow fixing a bug where KVM incorrectly leaves CR8 interception enabled when AVIC is activated without creating a mess with respect to whether AVIC is activated or not. Cc: stable@vger.kernel.org Fixes: |
||
|
Maxim Levitsky
|
b2a825c63c |
KVM: x86: Introduce KVM_X86_QUIRK_VMCS12_ALLOW_FREEZE_IN_SMM
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit e2ffe85b6d2bb7780174b87aa4468a39be17eb81 Author: Jim Mattson <jmattson@google.com> Date: Thu Feb 5 15:15:26 2026 -0800 KVM: x86: Introduce KVM_X86_QUIRK_VMCS12_ALLOW_FREEZE_IN_SMM Add KVM_X86_QUIRK_VMCS12_ALLOW_FREEZE_IN_SMM to allow L1 to set FREEZE_IN_SMM in vmcs12's GUEST_IA32_DEBUGCTL field, as permitted prior to commit 6b1dd26544d0 ("KVM: VMX: Preserve host's DEBUGCTLMSR_FREEZE_IN_SMM while running the guest"). Enable the quirk by default for backwards compatibility (like all quirks); userspace can disable it via KVM_CAP_DISABLE_QUIRKS2 for consistency with the constraints on WRMSR(IA32_DEBUGCTL). Note that the quirk only bypasses the consistency check. The vmcs02 bit is still owned by the host, and PMCs are not frozen during virtualized SMM. In particular, if a host administrator decides that PMCs should not be frozen during physical SMM, then L1 has no say in the matter. Fixes: 095686e6fcb4 ("KVM: nVMX: Check vmcs12->guest_ia32_debugctl on nested VM-Enter") Cc: stable@vger.kernel.org Signed-off-by: Jim Mattson <jmattson@google.com> Link: https://patch.msgid.link/20260205231537.1278753-1-jmattson@google.com [sean: tag for stable@, clean-up and fix goofs in the comment and docs] Signed-off-by: Sean Christopherson <seanjc@google.com> [Rename quirk. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
7324e2d984 |
KVM: x86: Fix SRCU list traversal in kvm_fire_mask_notifiers()
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit b54e4707a64be93a8ab3348e32e89817229b5eaa Author: Li RongQing <lirongqing@baidu.com> Date: Wed Feb 4 04:12:06 2026 -0500 KVM: x86: Fix SRCU list traversal in kvm_fire_mask_notifiers() The mask_notifier_list is protected by kvm->irq_srcu, but the traversal in kvm_fire_mask_notifiers() incorrectly uses hlist_for_each_entry_rcu(). This leads to lockdep warnings because the standard RCU iterator expects to be under rcu_read_lock(), not SRCU. Replace the RCU variant with hlist_for_each_entry_srcu() and provide the proper srcu_read_lock_held() annotation to ensure correct synchronization and silence lockdep. Signed-off-by: Li RongQing <lirongqing@baidu.com> Link: https://patch.msgid.link/20260204091206.2617-1-lirongqing@baidu.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
f2ef1985e5 |
KVM: VMX: Fix a wrong MSR update in add_atomic_switch_msr()
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit f78e627a01bd4ec0219566d2c9c40f3c3614f875 Author: Namhyung Kim <namhyung@kernel.org> Date: Fri Feb 20 14:02:16 2026 -0800 KVM: VMX: Fix a wrong MSR update in add_atomic_switch_msr() The previous change had a bug to update a guest MSR with a host value. Fixes: c3d6a7210a4de9096 ("KVM: VMX: Dedup code for adding MSR to VMCS's auto list") Signed-off-by: Namhyung Kim <namhyung@kernel.org> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20260220220216.389475-1-namhyung@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
8b624c005e |
KVM: x86: hyper-v: Validate all GVAs during PV TLB flush
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit a5264387c2ee42fca92ac792199008fc60ee82f1 Author: Manuel Andreas <manuel.andreas@tum.de> Date: Thu Feb 19 21:05:49 2026 +0100 KVM: x86: hyper-v: Validate all GVAs during PV TLB flush In KVM guests with Hyper-V hypercalls enabled, the hypercalls HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX allow a guest to request invalidation of portions of a virtual TLB. For this, the hypercall parameter includes a list of GVAs that are supposed to be invalidated. Currently, only the base GVA is checked to be canonical. In reality, this check needs to be performed for the entire range of GVAs, as checking only the base GVA enables guests running on Intel hardware to trigger a WARN_ONCE in the host (see Fixes commit below). Move the check for non-canonical addresses to be performed for every GVA of the supplied range to avoid the splat, and to be more in line with the Hyper-V specification, since, although unlikely, a range starting with an invalid GVA may still contain GVAs that are valid. Fixes: fa787ac07b3c ("KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush") Signed-off-by: Manuel Andreas <manuel.andreas@tum.de> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Link: https://patch.msgid.link/00a7a31b-573b-4d92-91f8-7d7e2f88ea48@tum.de [sean: massage changelog] Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
6602b6beba |
KVM: x86: synthesize CPUID bits only if CPU capability is set
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 4b3b8a8b0df1a5e7a1af04ff512df2c80db35dc8 Author: Carlos López <clopez@suse.de> Date: Mon Feb 9 16:31:09 2026 +0100 KVM: x86: synthesize CPUID bits only if CPU capability is set KVM incorrectly synthesizes CPUID bits for KVM-only leaves, as the following branch in kvm_cpu_cap_init() is never taken: if (leaf < NCAPINTS) kvm_cpu_caps[leaf] &= kernel_cpu_caps[leaf]; This means that bits set via SYNTHESIZED_F() for KVM-only leaves are unconditionally set. This for example can cause issues for SEV-SNP guests running on Family 19h CPUs, as TSA_SQ_NO and TSA_L1_NO are always enabled by KVM in 80000021[ECX]. When userspace issues a SNP_LAUNCH_UPDATE command to update the CPUID page for the guest, SNP firmware will explicitly reject the command if the page sets sets these bits on vulnerable CPUs. To fix this, check in SYNTHESIZED_F() that the corresponding X86 capability is set before adding it to to kvm_cpu_cap_features. Fixes: 31272abd5974 ("KVM: SVM: Advertise TSA CPUID bits to guests") Link: https://lore.kernel.org/all/20260208164233.30405-1-clopez@suse.de/ Signed-off-by: Carlos López <clopez@suse.de> Reviewed-by: Nikolay Borisov <nik.borisov@suse.com> Link: https://patch.msgid.link/20260209153108.70667-2-clopez@suse.de Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
fe9d9ad89a |
KVM: Remove subtle "struct kvm_stats_desc" pseudo-overlay
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit da142f3d373a6ddaca0119615a8db2175ddc4121 Author: Sean Christopherson <seanjc@google.com> Date: Fri Dec 5 15:26:55 2025 -0800 KVM: Remove subtle "struct kvm_stats_desc" pseudo-overlay Remove KVM's internal pseudo-overlay of kvm_stats_desc, which subtly aliases the flexible name[] in the uAPI definition with a fixed-size array of the same name. The unusual embedded structure results in compiler warnings due to -Wflex-array-member-not-at-end, and also necessitates an extra level of dereferencing in KVM. To avoid the "overlay", define the uAPI structure to have a fixed-size name when building for the kernel. Opportunistically clean up the indentation for the stats macros, and replace spaces with tabs. No functional change intended. Reported-by: Gustavo A. R. Silva <gustavoars@kernel.org> Closes: https://lore.kernel.org/all/aPfNKRpLfhmhYqfP@kspp Acked-by: Marc Zyngier <maz@kernel.org> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> [..] Acked-by: Anup Patel <anup@brainfault.org> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Acked-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://patch.msgid.link/20251205232655.445294-1-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
dde66e1996 |
KVM: x86: Add x2APIC "features" to control EOI broadcast suppression
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 6517dfbcc918f970a928d9dc17586904bac06893 Author: Khushit Shah <khushit.shah@nutanix.com> Date: Fri Jan 23 12:56:25 2026 +0000 KVM: x86: Add x2APIC "features" to control EOI broadcast suppression Add two flags for KVM_CAP_X2APIC_API to allow userspace to control support for Suppress EOI Broadcasts when using a split IRQCHIP (I/O APIC emulated by userspace), which KVM completely mishandles. When x2APIC support was first added, KVM incorrectly advertised and "enabled" Suppress EOI Broadcast, without fully supporting the I/O APIC side of the equation, i.e. without adding directed EOI to KVM's in-kernel I/O APIC. That flaw was carried over to split IRQCHIP support, i.e. KVM advertised support for Suppress EOI Broadcasts irrespective of whether or not the userspace I/O APIC implementation supported directed EOIs. Even worse, KVM didn't actually suppress EOI broadcasts, i.e. userspace VMMs without support for directed EOI came to rely on the "spurious" broadcasts. KVM "fixed" the in-kernel I/O APIC implementation by completely disabling support for Suppress EOI Broadcasts in commit |
||
|
Maxim Levitsky
|
aae5336ba6 |
KVM: x86: Harden against unexpected adjustments to kvm_cpu_caps
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 3f2757dbf32a31cef738a983bde6ecd2641484c0 Author: Sean Christopherson <seanjc@google.com> Date: Tue Jan 27 17:43:09 2026 -0800 KVM: x86: Harden against unexpected adjustments to kvm_cpu_caps Add a flag to track when KVM is actively configuring its CPU caps, and WARN if a cap is set or cleared if KVM isn't in its configuration stage. Modifying CPU caps after {svm,vmx}_set_cpu_caps() can be fatal to KVM, as vendor setup code expects the CPU caps to be frozen at that point, e.g. will do additional configuration based on the caps. Rename kvm_set_cpu_caps() to kvm_initialize_cpu_caps() to pair with the new "finalize", and to make it more obvious that KVM's CPU caps aren't fully configured within the function. Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://patch.msgid.link/20260128014310.3255561-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
8305c10a7e |
KVM: x86: Add SRCU protection for reading PDPTRs in __get_sregs2()
JIRA: https://issues.redhat.com/browse/RHEL-151869
commit 95d848dc7e639988dbb385a8cba9b484607cf98c
Author: Vasiliy Kovalev <kovalev@altlinux.org>
Date: Sat Jan 24 01:28:01 2026 +0300
KVM: x86: Add SRCU protection for reading PDPTRs in __get_sregs2()
Add SRCU read-side protection when reading PDPTR registers in
__get_sregs2().
Reading PDPTRs may trigger access to guest memory:
kvm_pdptr_read() -> svm_cache_reg() -> load_pdptrs() ->
kvm_vcpu_read_guest_page() -> kvm_vcpu_gfn_to_memslot()
kvm_vcpu_gfn_to_memslot() dereferences memslots via __kvm_memslots(),
which uses srcu_dereference_check() and requires either kvm->srcu or
kvm->slots_lock to be held. Currently only vcpu->mutex is held,
triggering lockdep warning:
=============================
WARNING: suspicious RCU usage in kvm_vcpu_gfn_to_memslot
6.12.59+ #3 Not tainted
include/linux/kvm_host.h:1062 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by syz.5.1717/15100:
#0: ff1100002f4b00b0 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x1d5/0x1590
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0xf0/0x120 lib/dump_stack.c:120
lockdep_rcu_suspicious+0x1e3/0x270 kernel/locking/lockdep.c:6824
__kvm_memslots include/linux/kvm_host.h:1062 [inline]
__kvm_memslots include/linux/kvm_host.h:1059 [inline]
kvm_vcpu_memslots include/linux/kvm_host.h:1076 [inline]
kvm_vcpu_gfn_to_memslot+0x518/0x5e0 virt/kvm/kvm_main.c:2617
kvm_vcpu_read_guest_page+0x27/0x50 virt/kvm/kvm_main.c:3302
load_pdptrs+0xff/0x4b0 arch/x86/kvm/x86.c:1065
svm_cache_reg+0x1c9/0x230 arch/x86/kvm/svm/svm.c:1688
kvm_pdptr_read arch/x86/kvm/kvm_cache_regs.h:141 [inline]
__get_sregs2 arch/x86/kvm/x86.c:11784 [inline]
kvm_arch_vcpu_ioctl+0x3e20/0x4aa0 arch/x86/kvm/x86.c:6279
kvm_vcpu_ioctl+0x856/0x1590 virt/kvm/kvm_main.c:4663
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl fs/ioctl.c:893 [inline]
__x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xbd/0x1d0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Suggested-by: Sean Christopherson <seanjc@google.com>
Cc: stable@vger.kernel.org
Fixes:
|
||
|
Maxim Levitsky
|
e72af51305 |
KVM: x86: Advertise AVX10_VNNI_INT CPUID to userspace
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 062768f426895b958417c85582826e20c44f477c Author: Zhao Liu <zhao1.liu@intel.com> Date: Thu Nov 20 13:07:20 2025 +0800 KVM: x86: Advertise AVX10_VNNI_INT CPUID to userspace Define and advertise AVX10_VNNI_INT CPUID to userspace when it's supported by the host. AVX10_VNNI_INT (0x24.0x1.ECX[bit 2]) is a discrete feature bit introduced on Intel Diamond Rapids, which enumerates the support for EVEX VPDP* instructions for INT8/INT16 [*]. Since this feature has no actual kernel usages, define it as a KVM-only feature in reverse_cpuid.h. Advertise new CPUID subleaf 0x24.0x1 with AVX10_VNNI_INT bit to userspace for guest use. It's safe since no additional enabling work is needed in the host kernel. [*]: Intel Advanced Vector Extensions 10.2 Architecture Specification (rev 5.0). Tested-by: Xudong Hao <xudong.hao@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Link: https://patch.msgid.link/20251120050720.931449-5-zhao1.liu@intel.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
3ce6e2cb96 |
KVM: x86: Advertise AVX10.2 CPUID to userspace
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 2ff8fb1e65e1a97f75f15935f84b9d2882a49623 Author: Zhao Liu <zhao1.liu@intel.com> Date: Thu Nov 20 13:07:19 2025 +0800 KVM: x86: Advertise AVX10.2 CPUID to userspace Bump up the maximum supported AVX10 version and enumerate AVX10.2 to userspace when it's supported by the host. Intel AVX10 Version 2 (Intel AVX10.2) includes a suite of new instructions delivering new AI features and performance, accelerated media processing, expanded Web Assembly, and Cryptography support, along with enhancements to existing legacy instructions for completeness and efficiency, and it is enumerated as version 2 in CPUID 0x24.0x0.EBX[bits 0-7] [1]. AVX10.2 has no current kernel usage and requires no additional host kernel enabling work (based on AVX10.1 support) and provides no new VMX controls [2]. Moreover, since AVX10.2 is the superset of AVX10.1, there's no need to worry about AVX10.1 and AVX10.2 compatibility issues in KVM. Therefore, it's safe to advertise AVX10.2 version to userspace directly if host supports AVX10.2. [1]: Intel Advanced Vector Extensions 10.2 Architecture Specification (rev 5.0). [2]: Note: Since AVX10.2 spec (rev 4.0), it has been declared "AVX10/512 will be used in all Intel products, supporting vector lengths of 128, 256, and 512 in all product lines", and the VMX support (in earlier revisions) for AVX10/256 guest on AVX10/512 host has been dropped. Tested-by: Xudong Hao <xudong.hao@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Link: https://patch.msgid.link/20251120050720.931449-4-zhao1.liu@intel.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
8d4941f6c7 |
KVM: x86: Advertise AMX CPUIDs in subleaf 0x1E.0x1 to userspace
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 58cbaf64e6530fa37752ff1362129842ac94fee0 Author: Zhao Liu <zhao1.liu@intel.com> Date: Thu Nov 20 13:07:18 2025 +0800 KVM: x86: Advertise AMX CPUIDs in subleaf 0x1E.0x1 to userspace Define and advertise AMX CPUIDs (0x1E.0x1) to userspace when the leaf is supported by the host. Intel Diamond Rapids adds new AMX instructions to support new formats and memory operations [*], and introduces the CPUID subleaf 0x1E.0x1 to centralize the discrete AMX feature bits within EAX. Since these AMX features have no actual kernel usages, define them as KVM-only features in reverse_cpuid.h. In addition to the new features, CPUID 0x1E.0x1.EAX[bits 0-3] are aliaseed positions of existing AMX feature bits distributed across the 0x7 leaves. To avoid duplicate feature names, name these aliases with an *_ALIAS suffix, and define them in reverse_cpuid.h as KVM-only features as well. Advertise new CPUID subleaf 0x1E.0x1 with its AMX CPUID feature bits to userspace for guest use. It's safe since no additional enabling work is needed in the host kernel. [*]: Intel Architecture Instruction Set Extensions and Future Features (rev.059). Tested-by: Xudong Hao <xudong.hao@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Link: https://patch.msgid.link/20251120050720.931449-3-zhao1.liu@intel.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
cccecd380b |
KVM: x86: Advertise MOVRS CPUID to userspace
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit f24ef0093dd8cf60ed7f93a82fb16335fdcbc310 Author: Zhao Liu <zhao1.liu@intel.com> Date: Thu Nov 20 13:07:17 2025 +0800 KVM: x86: Advertise MOVRS CPUID to userspace Define the feature flag for MOVRS and advertise support to userspace when the feature is supported by the host. MOVRS is a new set of instructions introduced in the Intel platform Diamond Rapids, to provide load instructions that carry a read-shared hint. Functionally, MOVRS family is equivalent to existing load instructions, but its read-shared hint indicates that the source memory location is likely to become read-shared by multiple processors, i.e., read in the future by at least one other processor before it is written (assuming it is ever written in the future). This hint could optimize the behavior of the caches, especially shared caches, for this data for future reads by multiple processors. Additionally, MOVRS family also includes a software prefetch instruction, PREFETCHRST2, that carries the same read-shared hint. [*] MOVRS family is enumerated by CPUID single-bit (0x7.0x1.EAX[bit 31]). Since it's on a densely-populated CPUID leaf and some other bits on this leaf have kernel usages, define this new feature in cpufeatures.h, but hide it in /proc/cpuinfo due to lack of current kernel usage. Advertise MOVRS bit to userspace directly. It's safe, since there's no new VMX controls or additional host enabling required for guests to use this feature. [*]: Intel Architecture Instruction Set Extensions and Future Features (rev.059). Tested-by: Xudong Hao <xudong.hao@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Link: https://patch.msgid.link/20251120050720.931449-2-zhao1.liu@intel.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
a3e06c6c42 |
KVM: SEV: Add KVM_SEV_SNP_ENABLE_REQ_CERTS command
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 20c3c4108d58f87c711bf44cb0b498b3ac5af6bf Author: Michael Roth <michael.roth@amd.com> Date: Fri Jan 9 17:17:33 2026 -0600 KVM: SEV: Add KVM_SEV_SNP_ENABLE_REQ_CERTS command Introduce a new command for KVM_MEMORY_ENCRYPT_OP ioctl that can be used to enable fetching of endorsement key certificates from userspace via the new KVM_EXIT_SNP_REQ_CERTS exit type. Also introduce a new KVM_X86_SEV_SNP_REQ_CERTS KVM device attribute so that userspace can query whether the kernel supports the new command/exit. Suggested-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Liam Merwick <liam.merwick@oracle.com> Tested-by: Liam Merwick <liam.merwick@oracle.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Link: https://patch.msgid.link/20260109231732.1160759-3-michael.roth@amd.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
6f33910297 |
KVM: Introduce KVM_EXIT_SNP_REQ_CERTS for SNP certificate-fetching
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit fa9893fadbc245e179cb17f3c371c67471b5a8a8 Author: Michael Roth <michael.roth@amd.com> Date: Fri Jan 9 17:17:32 2026 -0600 KVM: Introduce KVM_EXIT_SNP_REQ_CERTS for SNP certificate-fetching For SEV-SNP, the host can optionally provide a certificate table to the guest when it issues an attestation request to firmware (see GHCB 2.0 specification regarding "SNP Extended Guest Requests"). This certificate table can then be used to verify the endorsement key used by firmware to sign the attestation report. While it is possible for guests to obtain the certificates through other means, handling it via the host provides more flexibility in being able to keep the certificate data in sync with the endorsement key throughout host-side operations that might resulting in the endorsement key changing. In the case of KVM, userspace will be responsible for fetching the certificate table and keeping it in sync with any modifications to the endorsement key by other userspace management tools. Define a new KVM_EXIT_SNP_REQ_CERTS event where userspace is provided with the GPA of the buffer the guest has provided as part of the attestation request so that userspace can write the certificate data into it while relying on filesystem-based locking to keep the certificates up-to-date relative to the endorsement keys installed/utilized by firmware at the time the certificates are fetched. [Melody: Update the documentation scheme about how file locking is expected to happen.] Reviewed-by: Liam Merwick <liam.merwick@oracle.com> Tested-by: Liam Merwick <liam.merwick@oracle.com> Tested-by: Dionna Glaze <dionnaglaze@google.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Melody Wang <huibo.wang@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Link: https://patch.msgid.link/20260109231732.1160759-2-michael.roth@amd.com Signed-off-by: Sean Christopherson <seanjc@google.com> Conflicts: use final upstream value of KVM_EXIT_SNP_REQ_CERTS Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
3cf105b0dd |
KVM: x86: Drop WARN on INIT/SIPI being blocked when vCPU is in Wait-For-SIPI
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit c4a365cd4a4ec105012ab3ae5ff5cf11f8533771 Author: Sean Christopherson <seanjc@google.com> Date: Thu Jan 22 18:28:16 2026 -0800 KVM: x86: Drop WARN on INIT/SIPI being blocked when vCPU is in Wait-For-SIPI Drop the sanity check in kvm_apic_accept_events() that attempts to detect KVM bugs by asserting that a vCPU isn't in Wait-For-SIPI if INIT/SIPI are blocked, because if INIT is blocked, then it should be impossible for a vCPU to get into WFS in the first place. Unfortunately, syzbot is smarter than KVM (and its maintainers), and circumvented the guards put in place by commit 0fe3e8d804fd ("KVM: x86: Move INIT_RECEIVED vs. INIT/SIPI blocked check to KVM_RUN") by swapping the order and stuffing VMXON after INIT, and then triggering kvm_apic_accept_events() by way of KVM_GET_MP_STATE. Simply drop the WARN as it hasn't detected any meaningful KVM bugs in years (if ever?), and preventing userspace from clobbering guest state is generally a non-goal. More importantly, fully closing the hole would likely require enforcing some amount of ordering in KVM's ioctls, which is a much bigger risk than simply deleting the WARN. Reported-by: syzbot+59f2c3a3fc4f6c09b8cd@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6925da1b.a70a0220.d98e3.00b0.GAE@google.com Link: https://patch.msgid.link/20260123022816.2283567-1-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
0ec520cb05 |
KVM: selftests: Test READ=>WRITE dirty logging behavior for shadow MMU
JIRA: https://issues.redhat.com/browse/RHEL-151869
commit a91cc48246605af9aeef1edd32232976d74d9502
Author: Sean Christopherson <seanjc@google.com>
Date: Thu Jan 15 09:21:54 2026 -0800
KVM: selftests: Test READ=>WRITE dirty logging behavior for shadow MMU
Update the nested dirty log test to validate KVM's handling of READ faults
when dirty logging is enabled. Specifically, set the Dirty bit in the
guest PTEs used to map L2 GPAs, so that KVM will create writable SPTEs
when handling L2 read faults. When handling read faults in the shadow MMU,
KVM opportunistically creates a writable SPTE if the mapping can be
writable *and* the gPTE is dirty (or doesn't support the Dirty bit), i.e.
if KVM doesn't need to intercept writes in order to emulate Dirty-bit
updates.
To actually test the L2 READ=>WRITE sequence, e.g. without masking a false
pass by other test activity, route the READ=>WRITE and WRITE=>WRITE
sequences to separate L1 pages, and differentiate between "marked dirty
due to a WRITE access/fault" and "marked dirty due to creating a writable
SPTE for a READ access/fault". The updated sequence exposes the bug fixed
by KVM commit
|
||
|
Maxim Levitsky
|
9d9face9fe |
KVM: VMX: Print out "bad" offsets+value on VMCS config mismatch
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit c0d6b8bbbced660e9c2efe079e2b2cb34b27d97f Author: Sean Christopherson <seanjc@google.com> Date: Tue Jan 27 17:43:10 2026 -0800 KVM: VMX: Print out "bad" offsets+value on VMCS config mismatch When kvm-intel.ko refuses to load due to a mismatched VMCS config, print all mismatching offsets+values to make it easier to debug goofs during development, and to make it at least feasible to triage failures that occur during production. E.g. if a physical core is flaky or is running with the "wrong" microcode patch loaded, then a CPU can get a legitimate mismatch even without KVM bugs. Print the mismatches as 32-bit values as a compromise between hand coding every field (to provide precise information) and printing individual bytes (requires more effort to deduce the mismatch bit(s)). All fields in the VMCS config are either 32-bit or 64-bit values, i.e. in many cases, printing 32-bit values will be 100% precise, and in the others it's close enough, especially when considering that MSR values are split into EDX:EAX anyways. E.g. on mismatch CET entry/exit controls, KVM will print: kvm_intel: VMCS config on CPU 0 doesn't match reference config: Offset 76 REF = 0x107fffff, CPU0 = 0x007fffff, mismatch = 0x10000000 Offset 84 REF = 0x0010f3ff, CPU0 = 0x0000f3ff, mismatch = 0x00100000 Opportunistically tweak the wording on the initial error message to say "mismatch" instead of "inconsistent", as the VMCS config itself isn't inconsistent, and the wording conflates the cross-CPU compatibility check with the error_on_inconsistent_vmcs_config knob that treats inconsistent VMCS configurations as errors (e.g. if a CPU supports CET entry controls but no CET exit controls). Cc: Jim Mattson <jmattson@google.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://patch.msgid.link/20260128014310.3255561-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
f0989110e0 |
KVM: nVMX: Remove explicit filtering of GUEST_INTR_STATUS from shadow VMCS fields
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 1dc643205953c2ff2e1d95dbdc2e784675abb38c Author: Sean Christopherson <seanjc@google.com> Date: Thu Jan 15 09:34:27 2026 -0800 KVM: nVMX: Remove explicit filtering of GUEST_INTR_STATUS from shadow VMCS fields Drop KVM's filtering of GUEST_INTR_STATUS when generating the shadow VMCS bitmap now that KVM drops GUEST_INTR_STATUS from the set of supported vmcs12 fields if the field isn't supported by hardware, and initialization of the shadow VMCS fields omits unsupported vmcs12 fields. Note, there is technically a small functional change here, as the vmcs12 filtering only requires support for Virtual Interrupt Delivery, whereas the shadow VMCS code being removed required "full" APICv support, i.e. required Virtual Interrupt Delivery *and* APIC Register Virtualizaton *and* Posted Interrupt support. Opportunistically tweak the comment to more precisely explain why the PML and VMX preemption timer fields need to be explicitly checked. Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://patch.msgid.link/20260115173427.716021-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
38f4fe6e48 |
KVM: nVMX: Disallow access to vmcs12 fields that aren't supported by "hardware"
JIRA: https://issues.redhat.com/browse/RHEL-151869
commit 5fdf86e7353ce2d91a24dcbe7320935b40d55367
Author: Sean Christopherson <seanjc@google.com>
Date: Thu Jan 15 09:34:26 2026 -0800
KVM: nVMX: Disallow access to vmcs12 fields that aren't supported by "hardware"
Disallow access (VMREAD/VMWRITE), both emulated and via a shadow VMCS, to
VMCS fields that the loaded incarnation of KVM doesn't support, e.g. due
to lack of hardware support, as a middle ground between allowing access to
any vmcs12 field defined by KVM (current behavior) and gating access based
on the userspace-defined vCPU model (the most functionally correct, but
very costly, implementation).
Disallowing access to unsupported fields helps a tiny bit in terms of
closing the virtualization hole (see below), but the main motivation is to
avoid having to weed out unsupported fields when synchronizing between
vmcs12 and a shadow VMCS. Because shadow VMCS accesses are done via
VMREAD and VMWRITE, KVM _must_ filter out unsupported fields (or eat
VMREAD/VMWRITE failures), and filtering out just shadow VMCS fields is
about the same amount of effort, and arguably much more confusing.
As a bonus, this also fixes a KVM-Unit-Test failure bug when running on
_hardware_ without support for TSC Scaling, which fails with the same
signature as the bug fixed by commit
|
||
|
Maxim Levitsky
|
260c701c50 |
KVM: VMX: Add a wrapper around ROL16() to get a vmcs12 from a field encoding
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit c68feb605cc47431b3d86e6c2fe4f8342ebc87eb Author: Sean Christopherson <seanjc@google.com> Date: Thu Jan 15 09:34:25 2026 -0800 KVM: VMX: Add a wrapper around ROL16() to get a vmcs12 from a field encoding Add a wrapper macro, ENC_TO_VMCS12_IDX(), to get a vmcs12 index given a field encoding in anticipation of adding a macro to get from a vmcs12 index back to the field encoding. And because open coding ROL16(n, 6) everywhere is gross. No functional change intended. Suggested-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://patch.msgid.link/20260115173427.716021-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
0b8043b84e |
KVM: nVMX: Setup VMX MSRs on loading CPU during nested_vmx_hardware_setup()
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 26304e0e694f4cacc30bcf757663f26533351fbd Author: Sean Christopherson <seanjc@google.com> Date: Thu Jan 15 09:34:24 2026 -0800 KVM: nVMX: Setup VMX MSRs on loading CPU during nested_vmx_hardware_setup() Move the call to nested_vmx_setup_ctls_msrs() from vmx_hardware_setup() to nested_vmx_hardware_setup() so that the nested code can deal with ordering dependencies without having to straddle vmx_hardware_setup() and nested_vmx_hardware_setup(). Specifically, an upcoming change will sanitize the vmcs12 fields based on hardware support, and that code needs to run _before_ the MSRs are configured, because the lovely vmcs_enum MSR depends on the max support vmcs12 field. No functional change intended. Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://patch.msgid.link/20260115173427.716021-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
48cd987417 |
KVM: guest_memfd: GUP source pages prior to populating guest memory
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 2a62345b30529e488beb6a1220577b3495933724 Author: Michael Roth <michael.roth@amd.com> Date: Thu Jan 8 15:46:22 2026 -0600 KVM: guest_memfd: GUP source pages prior to populating guest memory Currently the post-populate callbacks handle copying source pages into private GPA ranges backed by guest_memfd, where kvm_gmem_populate() acquires the filemap invalidate lock, then calls a post-populate callback which may issue a get_user_pages() on the source pages prior to copying them into the private GPA (e.g. TDX). This will not be compatible with in-place conversion, where the userspace page fault path will attempt to acquire the filemap invalidate lock while holding the mm->mmap_lock, leading to a potential ABBA deadlock. Address this by hoisting the GUP above the filemap invalidate lock so that these page faults path can be taken early, prior to acquiring the filemap invalidate lock. It's not currently clear whether this issue is reachable with the current implementation of guest_memfd, which doesn't support in-place conversion, however it does provide a consistent mechanism to provide stable source/target PFNs to callbacks rather than punting to vendor-specific code, which allows for more commonality across architectures, which may be worthwhile even without in-place conversion. As part of this change, also begin enforcing that the 'src' argument to kvm_gmem_populate() must be page-aligned, as this greatly reduces the complexity around how the post-populate callbacks are implemented, and since no current in-tree users support using a non-page-aligned 'src' argument. Suggested-by: Sean Christopherson <seanjc@google.com> Co-developed-by: Sean Christopherson <seanjc@google.com> Co-developed-by: Vishal Annapurve <vannapurve@google.com> Signed-off-by: Vishal Annapurve <vannapurve@google.com> Tested-by: Vishal Annapurve <vannapurve@google.com> Tested-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Tested-by: Yan Zhao <yan.y.zhao@intel.com> Reviewed-by: Yan Zhao <yan.y.zhao@intel.com> Link: https://patch.msgid.link/20260108214622.1084057-7-michael.roth@amd.com [sean: avoid local "p" variable] Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
4686c5c4ff |
KVM: TDX: Document alignment requirements for KVM_TDX_INIT_MEM_REGION
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 189fd1b059a9c7ed22750bc8a4a1182c58ccf138 Author: Michael Roth <michael.roth@amd.com> Date: Thu Jan 8 15:46:21 2026 -0600 KVM: TDX: Document alignment requirements for KVM_TDX_INIT_MEM_REGION Since it was never possible to use a non-PAGE_SIZE-aligned @source_addr, go ahead and document this as a requirement. This is in preparation for enforcing page-aligned @source_addr for all architectures in guest_memfd. Reviewed-by: Vishal Annapurve <vannapurve@google.com> Tested-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Reviewed-by: Yan Zhao <yan.y.zhao@intel.com> Link: https://patch.msgid.link/20260108214622.1084057-6-michael.roth@amd.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
692be83bf5 |
KVM: SEV: Document/enforce page-alignment for KVM_SEV_SNP_LAUNCH_UPDATE
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit dcbcc2323c806b55939d765c13d0728421756017 Author: Michael Roth <michael.roth@amd.com> Date: Thu Jan 8 15:46:20 2026 -0600 KVM: SEV: Document/enforce page-alignment for KVM_SEV_SNP_LAUNCH_UPDATE In the past, KVM_SEV_SNP_LAUNCH_UPDATE accepted a non-page-aligned 'uaddr' parameter to copy data from, but continuing to support this with new functionality like in-place conversion and hugepages in the pipeline has proven to be more trouble than it is worth, since there are no known users that have been identified who use a non-page-aligned 'uaddr' parameter. Rather than locking guest_memfd into continuing to support this, go ahead and document page-alignment as a requirement and begin enforcing this in the handling function. Reviewed-by: Vishal Annapurve <vannapurve@google.com> Tested-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Link: https://patch.msgid.link/20260108214622.1084057-5-michael.roth@amd.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
e86995d9bf |
KVM: guest_memfd: Remove preparation tracking
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 8622ef05709fbc4903f54cdf1ac8c3725e479dd8 Author: Michael Roth <michael.roth@amd.com> Date: Thu Jan 8 15:46:19 2026 -0600 KVM: guest_memfd: Remove preparation tracking guest_memfd currently uses the folio uptodate flag to track: 1) whether or not a page has been cleared before initial usage 2) whether or not the architecture hooks have been issued to put the page in a private state as defined by the architecture In practice, (2) is only actually being tracked for SEV-SNP VMs, and there do not seem to be any plans/reasons that would suggest this will change in the future, so this additional tracking/complexity is not really providing any general benefit to guest_memfd users. On the other hand, future plans around in-place conversion and hugepage support will make the burden of tracking this information within guest_memfd even more complex. With in-place conversion and hugepage support, the plan is to use the per-folio uptodate flag purely to track the initial clearing of folios, whereas conversion operations could trigger multiple transitions between 'prepared' and 'unprepared' and thus need separate tracking. Since preparation generally happens during fault time, i.e. on the "read-side" of any VM-wide locks that might protect state tracked by guest_memfd, supporting concurrent handling of page faults would likely require more complex locking schemes if the "preparedness" state were tracked by guest_memfd, i.e. if it needs to be updated as part of handling the fault. Instead of keeping this current/future complexity within guest_memfd for what is essentially just SEV-SNP, just drop the tracking for (2) and have the arch-specific preparation hooks get triggered unconditionally on every fault so the arch-specific hooks can check the preparation state directly and decide whether or not a folio still needs additional preparation. In the case of SEV-SNP, the preparation state is already checked again via the preparation hooks to avoid double-preparation, so nothing extra needs to be done to update the handling of things there. Reviewed-by: Vishal Annapurve <vannapurve@google.com> Tested-by: Vishal Annapurve <vannapurve@google.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Tested-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Link: https://patch.msgid.link/20260108214622.1084057-4-michael.roth@amd.com [sean: massage changelog] Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
7c278d324f |
KVM: guest_memfd: Remove partial hugepage handling from kvm_gmem_populate()
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 6538b6221cc2feda415ca1946e66a5ef02dc6a0a Author: Michael Roth <michael.roth@amd.com> Date: Thu Jan 8 15:46:18 2026 -0600 KVM: guest_memfd: Remove partial hugepage handling from kvm_gmem_populate() kvm_gmem_populate(), and the associated post-populate callbacks, have some limited support for dealing with guests backed by hugepages by passing the order information along to each post-populate callback and iterating through the pages passed to kvm_gmem_populate() in hugepage-chunks. However, guest_memfd doesn't yet support hugepages, and in most cases additional changes in the kvm_gmem_populate() path would also be needed to actually allow for this functionality. This makes the existing code unnecessarily complex, and makes changes difficult to work through upstream due to theoretical impacts on hugepage support that can't be considered properly without an actual hugepage implementation to reference. So for now, remove what's there so changes for things like in-place conversion can be implemented/reviewed more efficiently. Suggested-by: Vishal Annapurve <vannapurve@google.com> Co-developed-by: Vishal Annapurve <vannapurve@google.com> Signed-off-by: Vishal Annapurve <vannapurve@google.com> Tested-by: Vishal Annapurve <vannapurve@google.com> Tested-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Tested-by: Yan Zhao <yan.y.zhao@intel.com> Reviewed-by: Yan Zhao <yan.y.zhao@intel.com> Link: https://patch.msgid.link/20260108214622.1084057-3-michael.roth@amd.com [sean: check for !IS_ERR() before checking folio_order()] Signed-off-by: Sean Christopherson <seanjc@google.com> Conflicts: missing ed1ffa810bd600a "KVM: guest_memfd: Enforce NUMA mempolicy using shared policy" Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
ecb625bc1e |
KVM: selftests: Add a selftests for nested VMLOAD/VMSAVE
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 55058e32151f95dc5badd62381d184e89f15de99 Author: Yosry Ahmed <yosry.ahmed@linux.dev> Date: Sat Jan 10 00:48:20 2026 +0000 KVM: selftests: Add a selftests for nested VMLOAD/VMSAVE Add a test for VMLOAD/VMSAVE in an L2 guest. The test verifies that L1 intercepts for VMSAVE/VMLOAD always work regardless of VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK. Then, more interestingly, it makes sure that when L1 does not intercept VMLOAD/VMSAVE, they work as intended in L2. When VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK is enabled by L1, VMSAVE/VMLOAD from L2 should interpret the GPA as an L2 GPA and translate it through the NPT. When VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK is disabled by L1, VMSAVE/VMLOAD from L2 should interpret the GPA as an L1 GPA. To test this, put two VMCBs (0 and 1) in L1's physical address space, and have a single L2 GPA where: - L2 VMCB GPA == L1 VMCB(0) GPA - L2 VMCB GPA maps to L1 VMCB(1) via the NPT in L1. This setup allows detecting how the GPA is interpreted based on which L1 VMCB is actually accessed. In both cases, L2 sets KERNEL_GS_BASE (one of the fields handled by VMSAVE/VMLOAD), and executes VMSAVE to write its value to the VMCB. The test userspace code then checks that the write was made to the correct VMCB (based on whether VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK is set by L1), and writes a new value to that VMCB. L2 then executes VMLOAD to load the new value and makes sure it's reflected correctly in KERNERL_GS_BASE. Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20260110004821.3411245-4-yosry.ahmed@linux.dev Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
0999f11d9c |
KVM: SVM: Stop toggling virtual VMSAVE/VMLOAD on intercept recalc
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 55780d8a1dcc93d2c4b33c565ada88df12c9f206 Author: Yosry Ahmed <yosry.ahmed@linux.dev> Date: Sat Jan 10 00:48:19 2026 +0000 KVM: SVM: Stop toggling virtual VMSAVE/VMLOAD on intercept recalc Virtual VMSAVE/VMLOAD enablement (i.e. VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK) is set/cleared by svm_recalc_instruction_intercepts() when the intercepts are cleared/set. This is unnecessary because the bit is meaningless when intercepts are set and KVM emulates the instructions. Initialize the bit in vmcb01 base on vls, and keep it unchanged. This is similar-ish to how vGIF is handled. It is enabled in init_vmcb() if vgif=1 and remains unchanged when the STGI intercept is enabled (e.g. for NMI windows). This fixes a bug in svm_recalc_instruction_intercepts(). The intercepts for VMSAVE/VMLOAD are always toggled in vmcb01, but VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK is toggled in the current VMCB, which could be vmcb02 instead of vmcb01 if L2 is active. Virtual VMSAVE/VMLOAD enablement in vmcb02 is separately controlled by nested_vmcb02_prepare_control() based on the vCPU features and VMCB12, and if intercepts are needed they are set by recalc_intercepts(). The bug is benign though. Not toggling the bit for vmcb01 is harmless because it's useless anyway. For vmcb02: - The bit could be incorrectly cleared when intercepts are set in vmcb01. This is harmless because VMSAVE/VMLOAD will be emulated by KVM anyway. - The bit could be incorrectly set when the intercepts are cleared in vmcb01. However, if the bit was originally clear in vmcb02, then recalc_intercepts() will enable in the intercepts in vmcb02 anyway and VMSAVE/VMLOAD will be emulated by KVM. Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20260110004821.3411245-3-yosry.ahmed@linux.dev Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
20e586d8f7 |
KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 127ccae2c185f62e6ecb4bf24f9cb307e9b9c619 Author: Yosry Ahmed <yosry.ahmed@linux.dev> Date: Sat Jan 10 00:48:18 2026 +0000 KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation Commit |
||
|
Maxim Levitsky
|
4604aad5dd |
KVM: VMX: Don't register posted interrupt wakeup handler if alloc_kvm_area() fails
JIRA: https://issues.redhat.com/browse/RHEL-151869
commit 6c8512a5b7f44caf981cee4ffa2a4ac73e627732
Author: Hou Wenlong <houwenlong.hwl@antgroup.com>
Date: Tue Jan 13 19:56:50 2026 +0800
KVM: VMX: Don't register posted interrupt wakeup handler if alloc_kvm_area() fails
Unregistering the posted interrupt wakeup handler only happens during
hardware unsetup. Therefore, if alloc_kvm_area() fails and continue to
register the posted interrupt wakeup handler, this will leave the global
posted interrupt wakeup handler pointer in an incorrect state. Although
it should not be an issue, it's still better to change it.
Signed-off-by: Hou Wenlong <houwenlong.hwl@antgroup.com>
Fixes:
|
||
|
Maxim Levitsky
|
9053cade6e |
KVM: nSVM: Drop redundant/wrong comment in nested_vmcb02_prepare_save()
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit f00ccdede3c84df2287e59b546fd92d58b7e07af Author: Yosry Ahmed <yosry.ahmed@linux.dev> Date: Tue Jan 13 17:28:07 2026 +0000 KVM: nSVM: Drop redundant/wrong comment in nested_vmcb02_prepare_save() The comment above DR6 and DR7 initializations is redundant, because the entire function follows the same pattern of only initializing the fields in vmcb02 if the vmcb12 changed or the fields are dirty, which handles the first execution case. Also, the comment refers to new_vmcb12 as new_vmcs12. Just drop the comment. No functional change intended. Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20260113172807.2178526-1-yosry.ahmed@linux.dev Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
d497f31f2a |
KVM: selftests: Slightly simplify memstress_setup_nested()
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit f756ed82c62aa2725757ac011710492d4cc8c7d8 Author: Yosry Ahmed <yosry.ahmed@linux.dev> Date: Tue Jan 13 17:14:56 2026 +0000 KVM: selftests: Slightly simplify memstress_setup_nested() Instead of calling memstress_setup_ept_mappings() only in the first iteration in the loop, move it before the loop. The call needed to happen within the loop before commit e40e72fec0de ("KVM: selftests: Stop passing VMX metadata to TDP mapping functions"), as memstress_setup_ept_mappings() used to take in a pointer to vmx_pages and pass it into tdp_identity_map_1g() (to get the EPT root GPA). This is no longer the case, as tdp_identity_map_1g() gets the EPT root through stage2 MMU. Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20260113171456.2097312-1-yosry.ahmed@linux.dev Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
6f3da74c43 |
KVM: VMX: Remove declaration of nested_mark_vmcs12_pages_dirty()
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit ac4f869c56301831a60706a84acbf13b4f0f9886 Author: Binbin Wu <binbin.wu@linux.intel.com> Date: Tue Jan 13 16:47:48 2026 +0800 KVM: VMX: Remove declaration of nested_mark_vmcs12_pages_dirty() Remove the declaration of nested_mark_vmcs12_pages_dirty() from the header file since it has been moved and renamed to nested_vmx_mark_all_vmcs12_pages_dirty(), which is a static function. Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://patch.msgid.link/20260113084748.1714633-1-binbin.wu@linux.intel.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
4bc3596ea7 |
KVM: SVM: Assert that Hyper-V's HV_SVM_EXITCODE_ENL == SVM_EXIT_SW
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit d6c20d19f7d3de14d02b47221988cdb19504bb84 Author: Sean Christopherson <seanjc@google.com> Date: Tue Dec 30 13:13:47 2025 -0800 KVM: SVM: Assert that Hyper-V's HV_SVM_EXITCODE_ENL == SVM_EXIT_SW Add a build-time assertiont that Hyper-V's "enlightened" exit code is that, same as the AMD-defined "Reserved for Host" exit code, mostly to help readers connect the dots and understand why synthesizing a software-defined exit code is safe/ok. Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Link: https://patch.msgid.link/20251230211347.4099600-9-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
67d6eb47aa |
KVM: SVM: Harden exit_code against being used in Spectre-like attacks
JIRA: https://issues.redhat.com/browse/RHEL-151869
commit 1e3dddafeceeb8d2cd182b78456cb9ca9d042a01
Author: Sean Christopherson <seanjc@google.com>
Date: Tue Dec 30 13:13:46 2025 -0800
KVM: SVM: Harden exit_code against being used in Spectre-like attacks
Explicitly clamp the exit code used to index KVM's exit handlers to guard
against Spectre-like attacks, mainly to provide consistency between VMX
and SVM (VMX was given the same treatment by commit
|
||
|
Maxim Levitsky
|
2e2fa1166d |
KVM: SVM: Limit incorrect check on SVM_EXIT_ERR to running as a VM
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit a08ca6691fd3ab40e40eb6600193672d50c7a7ba Author: Sean Christopherson <seanjc@google.com> Date: Tue Dec 30 13:13:45 2025 -0800 KVM: SVM: Limit incorrect check on SVM_EXIT_ERR to running as a VM Limit KVM's incorrect check for VMXEXIT_INVALID, a.k.a. SVM_EXIT_ERR, to running as a VM, as detected by X86_FEATURE_HYPERVISOR. The exit_code and all failure codes, e.g. VMXEXIT_INVALID, are 64-bit values, and so checking only bits 31:0 could result in false positives when running on non-broken hardware, e.g. in the extremely unlikely scenario exit code 0xffffffffull is ever generated by hardware. Keep the 32-bit check to play nice with running on broken KVM (for years, KVM has not set bits 63:32 when synthesizing nested SVM VM-Exits). Reviewed-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20251230211347.4099600-7-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
9c6207c7b3 |
KVM: SVM: Treat exit_code as an unsigned 64-bit value through all of KVM
JIRA: https://issues.redhat.com/browse/RHEL-151869
commit d7507a94a07202234236d7f94bed6015ca645ae6
Author: Sean Christopherson <seanjc@google.com>
Date: Tue Dec 30 13:13:44 2025 -0800
KVM: SVM: Treat exit_code as an unsigned 64-bit value through all of KVM
Fix KVM's long-standing buggy handling of SVM's exit_code as a 32-bit
value. Per the APM and Xen commit d1bd157fbc ("Big merge the HVM
full-virtualisation abstractions.") (which is arguably more trustworthy
than KVM), offset 0x70 is a single 64-bit value:
070h 63:0 EXITCODE
Track exit_code as a single u64 to prevent reintroducing bugs where KVM
neglects to correctly set bits 63:32.
Fixes:
|
||
|
Maxim Levitsky
|
8a280746e7 |
KVM: SVM: Filter out 64-bit exit codes when invoking exit handlers on bare metal
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 405fce694bd1589082a7ffd500b5a4b841c22f0d Author: Sean Christopherson <seanjc@google.com> Date: Tue Dec 30 13:13:43 2025 -0800 KVM: SVM: Filter out 64-bit exit codes when invoking exit handlers on bare metal Explicitly filter out 64-bit exit codes when invoking exit handlers, as svm_exit_handlers[] will never be sized with entries that use bits 63:32. Processing the non-failing exit code as a 32-bit value will allow tracking exit_code as a single 64-bit value (which it is, architecturally). This will also allow hardening KVM against Spectre-like attacks without needing to do silly things to avoid build failures on 32-bit kernels (array_index_nospec() rightly asserts that the index fits in an "unsigned long"). Omit the check when running as a VM, as KVM has historically failed to set bits 63:32 appropriately when synthesizing VM-Exits, i.e. KVM could get false positives when running as a VM on an older, broken KVM/kernel. From a functional perspective, omitting the check is "fine", as any unwanted collision between e.g. VMEXIT_INVALID and a 32-bit exit code will be fatal to KVM-on-KVM regardless of what KVM-as-L1 does. Reviewed-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20251230211347.4099600-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
c37418334a |
KVM: SVM: Check for an unexpected VM-Exit after RETPOLINE "fast" handling
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 194c17bf5ebadd2fcf52ac641793e3d755a7af55 Author: Sean Christopherson <seanjc@google.com> Date: Tue Dec 30 13:13:42 2025 -0800 KVM: SVM: Check for an unexpected VM-Exit after RETPOLINE "fast" handling Check for an unexpected/unhandled VM-Exit after the manual RETPOLINE=y handling. The entire point of the RETPOLINE checks is to optimize for common VM-Exits, i.e. checking for the rare case of an unsupported VM-Exit is counter-productive. This also aligns SVM and VMX exit handling. No functional change intended. Reviewed-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20251230211347.4099600-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
86a73556bd |
KVM: SVM: Open code handling of unexpected exits in svm_invoke_exit_handler()
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 2450c9774510e45c506df4a1b46d129435993ff6 Author: Sean Christopherson <seanjc@google.com> Date: Tue Dec 30 13:13:41 2025 -0800 KVM: SVM: Open code handling of unexpected exits in svm_invoke_exit_handler() Fold svm_check_exit_valid() and svm_handle_invalid_exit() into their sole caller, svm_invoke_exit_handler(), as having tiny single-use helpers makes the code unncessarily difficult to follow. This will also allow for additional cleanups in svm_invoke_exit_handler(). No functional change intended. Suggested-by: Yosry Ahmed <yosry.ahmed@linux.dev> Reviewed-by: Yosry Ahmed <yosry.ahmed@linux.dev> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Link: https://patch.msgid.link/20251230211347.4099600-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
b08aac8e3a |
KVM: SVM: Add a helper to detect VMRUN failures
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 217463aa329ea9a2efafd1bbfa6787e8df9091b9 Author: Sean Christopherson <seanjc@google.com> Date: Tue Dec 30 13:13:40 2025 -0800 KVM: SVM: Add a helper to detect VMRUN failures Add a helper to detect VMRUN failures so that KVM can guard against its own long-standing bug, where KVM neglects to set exitcode[63:32] when synthesizing a nested VMFAIL_INVALID VM-Exit. This will allow fixing KVM's mess of treating exitcode as two separate 32-bit values without breaking KVM-on-KVM when running on an older, unfixed KVM. Cc: Jim Mattson <jmattson@google.com> Cc: Yosry Ahmed <yosry.ahmed@linux.dev> Reviewed-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20251230211347.4099600-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
dca7b13e63 |
KVM: x86: align the code with kvm_x86_call()
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit de0dc71188ca54cfe13fac5c4334715fb37fe8ce Author: Jun Miao <jun.miao@intel.com> Date: Mon Jan 5 14:54:23 2026 +0800 KVM: x86: align the code with kvm_x86_call() The use of static_call_cond() is essentially the same as static_call() on x86 (e.g. static_call() now handles a NULL pointer as a NOP), and then the kvm_x86_call() is added to improve code readability and maintainability for keeping consistent code style. Fixes 8d032b683c29 ("KVM: TDX: create/destroy VM structure") Link: https://lore.kernel.org/all/3916caa1dcd114301a49beafa5030eca396745c1.1679456900.git.jpoimboe@kernel.org/ Link: https://lore.kernel.org/r/20240507133103.15052-3-wei.w.wang@intel.com Signed-off-by: Jun Miao <jun.miao@intel.com> Link: https://patch.msgid.link/20260105065423.1870622-1-jun.miao@intel.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
cbed8355ec |
KVM: x86: Ignore -EBUSY when checking nested events from vcpu_block()
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit ead63640d4e72e6f6d464f4e31f7fecb79af8869 Author: Sean Christopherson <seanjc@google.com> Date: Thu Jan 8 19:06:57 2026 -0800 KVM: x86: Ignore -EBUSY when checking nested events from vcpu_block() Ignore -EBUSY when checking nested events after exiting a blocking state while L2 is active, as exiting to userspace will generate a spurious userspace exit, usually with KVM_EXIT_UNKNOWN, and likely lead to the VM's demise. Continuing with the wakeup isn't perfect either, as *something* has gone sideways if a vCPU is awakened in L2 with an injected event (or worse, a nested run pending), but continuing on gives the VM a decent chance of surviving without any major side effects. As explained in the Fixes commits, it _should_ be impossible for a vCPU to be put into a blocking state with an already-injected event (exception, IRQ, or NMI). Unfortunately, userspace can stuff MP_STATE and/or injected events, and thus put the vCPU into what should be an impossible state. Don't bother trying to preserve the WARN, e.g. with an anti-syzkaller Kconfig, as WARNs can (hopefully) be added in paths where _KVM_ would be violating x86 architecture, e.g. by WARNing if KVM attempts to inject an exception or interrupt while the vCPU isn't running. Cc: Alessandro Ratti <alessandro@0x65c.net> Cc: stable@vger.kernel.org Fixes: |
||
|
Maxim Levitsky
|
cb36886e79 |
KVM: SVM: Tag sev_supported_vmsa_features as read-only after init
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit d23051f59a5b4eb1f6163cf27e07b8cfcaeb4758 Author: Sean Christopherson <seanjc@google.com> Date: Thu Jan 8 19:31:01 2026 -0800 KVM: SVM: Tag sev_supported_vmsa_features as read-only after init Tag sev_supported_vmsa_features with __ro_after_init as it's configured by sev_hardware_setup() and never written after initial configuration (and if it were, that'd be a blatant bug). Opportunistically relocate the variable out of the module params area now that sev_es_debug_swap_enabled is gone (which largely motivated its original location). Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://patch.msgid.link/20260109033101.1005769-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
22ec3221b8 |
KVM: SVM: Drop the module param to control SEV-ES DebugSwap
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 9587dd7a7ebd7be3c36815a4c4f90f7e2cedbe03 Author: Sean Christopherson <seanjc@google.com> Date: Thu Jan 8 19:31:00 2026 -0800 KVM: SVM: Drop the module param to control SEV-ES DebugSwap Rip out the DebugSwap module param, as the sequence of events that led to its inclusion was one big mistake, the param no longer serves any purpose. Commit |
||
|
Maxim Levitsky
|
9cb4ac465f |
KVM: x86: Update APICv ISR (a.k.a. SVI) as part of kvm_apic_update_apicv()
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 000d75b0b18622e7454c3955631a3cf39e0353e7 Author: Sean Christopherson <seanjc@google.com> Date: Thu Jan 8 19:45:32 2026 -0800 KVM: x86: Update APICv ISR (a.k.a. SVI) as part of kvm_apic_update_apicv() Fold the calls to .hwapic_isr_update() in kvm_apic_set_state(), kvm_lapic_reset(), and __kvm_vcpu_update_apicv() into kvm_apic_update_apicv(), as updating SVI is directly related to updating KVM's own cache of ISR information, e.g. SVI is more or less the APICv equivalent of highest_isr_cache. Note, calling .hwapic_isr_update() during kvm_apic_update_apicv() has benign side effects, as doing so changes the orders of the calls in kvm_lapic_reset() and kvm_apic_set_state(), specifically with respect to to the order between .hwapic_isr_update() and .apicv_post_state_restore(). However, the changes in ordering are glorified nops as the former hook is VMX-only and the latter is SVM-only. Reviewed-by: Chao Gao <chao.gao@intel.com> Link: https://patch.msgid.link/20260109034532.1012993-9-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
1aabe4ee78 |
KVM: nVMX: Switch to vmcs01 to set virtual APICv mode on-demand if L2 is active
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 249cc1ab4b9a5caa63d7e9c5a5b7862046089dd4 Author: Sean Christopherson <seanjc@google.com> Date: Thu Jan 8 19:45:31 2026 -0800 KVM: nVMX: Switch to vmcs01 to set virtual APICv mode on-demand if L2 is active If L1's virtual APIC mode changes while L2 is active, e.g. because L1 doesn't intercept writes to the APIC_BASE MSR and L2 changes the mode, temporarily load vmcs01 and do all of the necessary actions instead of deferring the update until the next nested VM-Exit. This will help in fixing yet more issues related to updates while L2 is active, e.g. KVM neglects to update vmcs02 MSR intercepts if vmcs01's MSR intercepts are modified while L2 is active. Not updating x2APIC MSRs is benign because vmcs01's settings are not factored into vmcs02's bitmap, but deferring the x2APIC MSR updates would create a weird, inconsistent state. Reviewed-by: Chao Gao <chao.gao@intel.com> Link: https://patch.msgid.link/20260109034532.1012993-8-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
9a8fac6abc |
KVM: nVMX: Switch to vmcs01 to update APIC page on-demand if L2 is active
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 51c821d6d0ba038506d8b1c522f0b2b0ed756dd3 Author: Sean Christopherson <seanjc@google.com> Date: Thu Jan 8 19:45:30 2026 -0800 KVM: nVMX: Switch to vmcs01 to update APIC page on-demand if L2 is active If the KVM-owned APIC-access page is migrated while L2 is running, temporarily load vmcs01 and immediately update APIC_ACCESS_ADDR instead of deferring the update until the next nested VM-Exit. Once changing the virtual APIC mode is converted to always do on-demand updates, all of the "defer until vmcs01 is active" logic will be gone. Reviewed-by: Chao Gao <chao.gao@intel.com> Link: https://patch.msgid.link/20260109034532.1012993-7-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
8cae51cf5f |
KVM: nVMX: Switch to vmcs01 to refresh APICv controls on-demand if L2 is active
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 2bf889a68fbab33133ef9ec1000399913b2c65c4 Author: Sean Christopherson <seanjc@google.com> Date: Thu Jan 8 19:45:29 2026 -0800 KVM: nVMX: Switch to vmcs01 to refresh APICv controls on-demand if L2 is active If APICv is (un)inhibited while L2 is running, temporarily load vmcs01 and immediately refresh the APICv controls in vmcs01 instead of deferring the update until the next nested VM-Exit. This all but eliminates potential ordering issues due to vmcs01 not being synchronized with kvm_lapic.apicv_active, e.g. where KVM _thinks_ it refreshed APICv, but vmcs01 still contains stale state. Reviewed-by: Chao Gao <chao.gao@intel.com> Link: https://patch.msgid.link/20260109034532.1012993-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
76c1706d2f |
KVM: nVMX: Switch to vmcs01 to update SVI on-demand if L2 is active
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit f0044429b257c015f95b8e110c652446d4fcfe4c Author: Sean Christopherson <seanjc@google.com> Date: Thu Jan 8 19:45:28 2026 -0800 KVM: nVMX: Switch to vmcs01 to update SVI on-demand if L2 is active If APICv is activated while L2 is running and triggers an SVI update, temporarily load vmcs01 and immediately update SVI instead of deferring the update until the next nested VM-Exit. This will eventually allow killing off kvm_apic_update_hwapic_isr(), and all of nVMX's deferred APICv updates. Reviewed-by: Chao Gao <chao.gao@intel.com> Link: https://patch.msgid.link/20260109034532.1012993-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
09e93ee0a2 |
KVM: nVMX: Switch to vmcs01 to update TPR threshold on-demand if L2 is active
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 51ca2746078ef9390db91251805e54eff3601d63 Author: Sean Christopherson <seanjc@google.com> Date: Thu Jan 8 19:45:27 2026 -0800 KVM: nVMX: Switch to vmcs01 to update TPR threshold on-demand if L2 is active If KVM updates L1's TPR Threshold while L2 is active, temporarily load vmcs01 and immediately update TPR_THRESHOLD instead of deferring the update until the next nested VM-Exit. Deferring the TPR Threshold update is relatively straightforward, but for several APICv related updates, deferring updates creates ordering and state consistency problems, e.g. KVM at-large thinks APICv is enabled, but vmcs01 is still running with stale (and effectively unknown) state. Reviewed-by: Chao Gao <chao.gao@intel.com> Link: https://patch.msgid.link/20260109034532.1012993-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
1cbaa1d873 |
KVM: nVMX: Switch to vmcs01 to update PML controls on-demand if L2 is active
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 3e013d0a70994df2c2ba78d599a6c039ab0977a5 Author: Sean Christopherson <seanjc@google.com> Date: Thu Jan 8 19:45:26 2026 -0800 KVM: nVMX: Switch to vmcs01 to update PML controls on-demand if L2 is active If KVM toggles "CPU dirty logging", a.k.a. Page-Modification Logging (PML), while L2 is active, temporarily load vmcs01 and immediately update the relevant controls instead of deferring the update until the next nested VM-Exit. For PML, deferring the update is relatively straightforward, but for several APICv related updates, deferring updates creates ordering and state consistency problems, e.g. KVM at-large thinks APICv is enabled, but vmcs01 is still running with stale (and effectively unknown) state. Convert PML first precisely because it's the simplest case to handle: if something is broken with the vmcs01 <=> vmcs02 dance, then hopefully bugs will bisect here. Reviewed-by: Chao Gao <chao.gao@intel.com> Link: https://patch.msgid.link/20260109034532.1012993-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
bd04b85b43 |
KVM: selftests: Add a test to verify APICv updates (while L2 is active)
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit c3a9a27c79e4e5d8bdb20a26d16230111207e98e Author: Sean Christopherson <seanjc@google.com> Date: Thu Jan 8 19:45:25 2026 -0800 KVM: selftests: Add a test to verify APICv updates (while L2 is active) Add a test to verify KVM correctly handles a variety of edge cases related to APICv updates, and in particular updates that are triggered while L2 is actively running. Reviewed-by: Chao Gao <chao.gao@intel.com> Link: https://patch.msgid.link/20260109034532.1012993-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
c5e3e552fb |
KVM: SVM: Fix a missing kunmap_local() in sev_gmem_post_populate()
JIRA: https://issues.redhat.com/browse/RHEL-151869
commit 60b590de8b30dad8b11e9e4fba0df2eae81afb98
Author: Yan Zhao <yan.y.zhao@intel.com>
Date: Thu Jan 8 15:46:17 2026 -0600
KVM: SVM: Fix a missing kunmap_local() in sev_gmem_post_populate()
sev_gmem_post_populate() needs to unmap the target vaddr after
copy_from_user() to the vaddr fails.
Fixes:
|
||
|
Maxim Levitsky
|
da3b60582d |
KVM: x86: Hide KVM_IRQCHIP_KERNEL behind CONFIG_KVM_IOAPIC=y
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit fd09d259c161086849774f9261cab16c58ba7dff Author: Sean Christopherson <seanjc@google.com> Date: Fri Dec 5 16:43:11 2025 -0800 KVM: x86: Hide KVM_IRQCHIP_KERNEL behind CONFIG_KVM_IOAPIC=y Enumerate KVM_IRQCHIP_KERNEL if and only if support for an in-kernel I/O APIC is enabled, as all usage is likewise guarded by CONFIG_KVM_IOAPIC=y. Link: https://patch.msgid.link/20251206004311.479939-10-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
e7b157756a |
KVM: x86: Bury ioapic.h definitions behind CONFIG_KVM_IOAPIC
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 59c3e0603d8614e0f5e17089182ca596cf3fc552 Author: Sean Christopherson <seanjc@google.com> Date: Fri Dec 5 16:43:10 2025 -0800 KVM: x86: Bury ioapic.h definitions behind CONFIG_KVM_IOAPIC Now that almost everything in ioapic.h is used only by code guarded by CONFIG_KVM_IOAPIC=y, bury (almost) the entire thing behind the Kconfig. Link: https://patch.msgid.link/20251206004311.479939-9-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
7e97501817 |
KVM: x86: Fold "struct dest_map" into "struct rtc_status"
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 5cd6b1a6eebd564104897ca87be2812d8feafad4 Author: Sean Christopherson <seanjc@google.com> Date: Fri Dec 5 16:43:09 2025 -0800 KVM: x86: Fold "struct dest_map" into "struct rtc_status" Drop "struct dest_map" and fold its members into its one and only user, "struct rtc_status". Tracking "pending" EOIs and associated vCPUs is very much a hack for legacy RTC behavior, and should never be needed for other IRQ delivery. In addition to making it more obvious why KVM tracks target vCPUs, this will allow burying the "struct rtc_status" definition behind CONFIG_KVM_IOAPIC=y, which in turn will make it even harder for KVM to misuse the structure. No functional change intended. Link: https://patch.msgid.link/20251206004311.479939-8-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
e9b1783daa |
KVM: x86: Add a wrapper to handle common case of IRQ delivery without dest_map
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 1a5d7f9540af1416402887435e4537dcef36a4b2 Author: Sean Christopherson <seanjc@google.com> Date: Fri Dec 5 16:43:08 2025 -0800 KVM: x86: Add a wrapper to handle common case of IRQ delivery without dest_map Turn kvm_irq_delivery_to_apic() into a wrapper that passes NULL for the @dest_map param, as only the ugly I/O APIC RTC hackery needs to know which vCPUs received the IRQ. No functional change intended. Link: https://patch.msgid.link/20251206004311.479939-7-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
addea13476 |
KVM: x86: Drop MAX_NR_RESERVED_IOAPIC_PINS, use KVM_MAX_IRQ_ROUTES directly
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 4d846f183897606ba5e9c76494d19acbe1ba88f9 Author: Sean Christopherson <seanjc@google.com> Date: Fri Dec 5 16:43:07 2025 -0800 KVM: x86: Drop MAX_NR_RESERVED_IOAPIC_PINS, use KVM_MAX_IRQ_ROUTES directly Directly use KVM_MAX_IRQ_ROUTES when checking the number of routes being defined by userspace when creating a split IRQCHIP. The restriction has nothing to do with the I/O APIC, e.g. most modern userspace usage is for routing MSIs. Breaking the unnecessary dependency on the I/O APIC will allow burying all of ioapic.h behind CONFIG_KVM_IOAPIC=y. No functional change intended. Link: https://patch.msgid.link/20251206004311.479939-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
6aa25e8df9 |
KVM: x86: Drop guest-triggerable ASSERT()s on I/O APIC access alignment
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 9eabb2a5e499ec3e5a013157844335a487c7cb5e Author: Sean Christopherson <seanjc@google.com> Date: Fri Dec 5 16:43:06 2025 -0800 KVM: x86: Drop guest-triggerable ASSERT()s on I/O APIC access alignment Drop the asserts on the guest-controlled address being 16-byte aligned when emulating I/O APIC accesses, as the ASSERT()s are guest-triggerable and ultimately pointless since KVM requires exact register matches, i.e. will ultimately ignore unaligned accesses anyways. Drop the ASSERT() definition itself now that all users are gone. For all intents and purposes, no functional change intended. Link: https://patch.msgid.link/20251206004311.479939-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
48c88f432f |
KVM: x86: Drop ASSERT() on I/O APIC EOIs being only for LEVEL_to WARN_ON_ONCE
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit ca909f9ea8cb19032c9d9d7841a8e2395b6a9e8b Author: Sean Christopherson <seanjc@google.com> Date: Fri Dec 5 16:43:05 2025 -0800 KVM: x86: Drop ASSERT() on I/O APIC EOIs being only for LEVEL_to WARN_ON_ONCE Remove kvm_ioapic_update_eoi_one()'s ASSERT() that the vector's entry is configured to be level-triggered, as KVM intercepts and forward EOIs to the I/O APIC even for edge-triggered IRQs (see kvm_ioapic_scan_entry()), and nothing guarantees the local APIC's TMR register is synchronized with the I/O APIC redirection table, i.e. the @trigger_mode check just out of sight doesn't provide any meaningful protection. Given that roughly half of the historic ASSERT()s are/were guest- and/or user-triggerable, it's safe to assume no one has run meaningful workloads with DEBUG=1, i.e. that the ASSERT() has been dead code since it was added 18+ years ago. Opportunistically drop the unnecessary forward declaration of kvm_ioapic_update_eoi_one(). For all intents and purposes, no functional change intended. Link: https://patch.msgid.link/20251206004311.479939-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
a9e502a85c |
KVM: x86: Drop guest/user-triggerable asserts on IRR/ISR vectors
JIRA: https://issues.redhat.com/browse/RHEL-151869
commit 37187992dd821e0283da3f7664ef3d6ab4220ef8
Author: Sean Christopherson <seanjc@google.com>
Date: Fri Dec 5 16:43:04 2025 -0800
KVM: x86: Drop guest/user-triggerable asserts on IRR/ISR vectors
Remove the ASSERT()s in apic_find_highest_i{r,s}r() that exist to detect
illegal vectors (0-15 are reserved and never recognized by the local APIC),
as the asserts, if they were ever to be enabled by #defining DEBUG, can be
trivially triggered from both the guest and from userspace, and ultimately
because the ASSERT()s are useless.
In large part due to lack of emulation for the Error Status Register and
its "delayed" read semantics, KVM doesn't filter out bad IRQs (IPIs or
otherwise) when IRQs are sent or received. Instead, probably by dumb
luck on KVM's part, KVM effectively ignores pending illegal vectors in
the IRR due vector 0-15 having priority '0', and thus never being higher
priority than PPR.
As for ISR, a misbehaving userspace could stuff illegal vector bits, but
again the end result is mostly benign (aside from userspace likely
breaking the VM), as processing illegal vectors "works" and doesn't cause
functional problems.
Regardless of the safety and correctness of KVM's illegal vector handling,
one thing is for certain: the ASSERT()s have done absolutely nothing to
help detect such issues since they were added 18+ years ago by commit
|
||
|
Maxim Levitsky
|
2609a982f2 |
KVM: x86: Drop ASSERT()s on APIC/vCPU being non-NULL
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit a4978324e4bd80427313e0baa16e53709e14d878 Author: Sean Christopherson <seanjc@google.com> Date: Fri Dec 5 16:43:03 2025 -0800 KVM: x86: Drop ASSERT()s on APIC/vCPU being non-NULL Remove ASSERT()s on vCPU and APIC structures being non-NULL in the local APIC code as the DEBUG=1 path of ASSERT() ends with BUG(), i.e. isn't meaningfully better for debugging than a NULL pointer dereference. For all intents and purposes, no functional change intended. Link: https://patch.msgid.link/20251206004311.479939-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
dd45d1ade6 |
KVM: selftests: Extend vmx_set_nested_state_test to cover SVM
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit ca2eccb953fd33ef38701e33e660b21f7e84aa14 Author: Yosry Ahmed <yosry.ahmed@linux.dev> Date: Fri Nov 21 20:48:03 2025 +0000 KVM: selftests: Extend vmx_set_nested_state_test to cover SVM Add test cases for the validation checks in svm_set_nested_state(), and allow the test to run with SVM as well as VMX. The SVM test also makes sure that KVM_SET_NESTED_STATE accepts GIF being set or cleared if EFER.SVME is cleared, verifying a recently fixed bug where GIF was incorrectly expected to always be set when EFER.SVME is cleared. Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20251121204803.991707-5-yosry.ahmed@linux.dev Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
12912652ce |
KVM: selftests: Use TEST_ASSERT_EQ() in test_vmx_nested_state()
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit bda6ae6f29664b659671f872a2adda3c1c2f5dd6 Author: Yosry Ahmed <yosry.ahmed@linux.dev> Date: Fri Nov 21 20:48:02 2025 +0000 KVM: selftests: Use TEST_ASSERT_EQ() in test_vmx_nested_state() The assert messages do not add much value, so use TEST_ASSERT_EQ(), which also nicely displays the addresses in hex. While at it, also assert the values of state->flags. Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20251121204803.991707-4-yosry.ahmed@linux.dev Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
85e53f64fc |
KVM: SVM: Allow KVM_SET_NESTED_STATE to clear GIF when SVME==0
JIRA: https://issues.redhat.com/browse/RHEL-151869
commit 6f4d3ebc24c6ef92e196ebbd389a3f2bfdc7a144
Author: Jim Mattson <jmattson@google.com>
Date: Fri Nov 21 20:48:00 2025 +0000
KVM: SVM: Allow KVM_SET_NESTED_STATE to clear GIF when SVME==0
GIF==0 together with EFER.SVME==0 is a valid architectural
state. Don't return -EINVAL for KVM_SET_NESTED_STATE when this
combination is specified.
Fixes:
|
||
|
Maxim Levitsky
|
bf2f7da378 |
KVM: SVM: Don't set GIF when clearing EFER.SVME
JIRA: https://issues.redhat.com/browse/RHEL-151869
commit 8312f1b9dd71340b5fff65e56c6c163187bfa5d0
Author: Jim Mattson <jmattson@google.com>
Date: Fri Nov 21 20:48:01 2025 +0000
KVM: SVM: Don't set GIF when clearing EFER.SVME
Clearing EFER.SVME is not architected to set GIF. Don't set GIF when
emulating a change to EFER that clears EFER.SVME.
However, keep setting GIF if clearing EFER.SVME causes force-leaving the
nested guest through svm_leave_nested(), to maintain a sane behavior of
not leaving GIF cleared after exiting the guest. In every other path,
setting GIF is either correct/desirable, or irrelevant because the
caller immediately and unconditionally sets/clears GIF.
This is more-or-less KVM defining HW behavior, but leaving GIF cleared
would also be defining HW behavior anyway.
Note that if force-leaving the nested guest is considered a SHUTDOWN,
then this could violate the APM-specified behavior:
If the processor enters the shutdown state (due to a triple fault for
instance) while GIF is clear, it can only be restarted by means of a
RESET.
However, a SHUTDOWN leaves the VMCB undefined, so there's not a lot that
KVM can do in this case. Also, if vGIF is enabled on SHUTDOWN, KVM has
no way of finding out of GIF was cleared.
The only way for KVM to handle this without making up HW behavior is to
completely terminate the VM, so settle for doing the relatively "sane"
thing of setting GIF when force-leaving nested.
Fixes:
|
||
|
Maxim Levitsky
|
49257e1f77 |
KVM: SVM: Virtualize and advertise support for ERAPS
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit db5e82496492b4890b1c3356581c016767ed527f Author: Amit Shah <amit.shah@amd.com> Date: Fri Nov 7 10:32:39 2025 +0100 KVM: SVM: Virtualize and advertise support for ERAPS AMD CPUs with the Enhanced Return Address Predictor Security (ERAPS) feature (available on Zen5+) obviate the need for FILL_RETURN_BUFFER sequences right after VMEXITs. ERAPS adds guest/host tags to entries in the RSB (a.k.a. RAP). This helps with speculation protection across the VM boundary, and it also preserves host and guest entries in the RSB that can improve software performance (which would otherwise be flushed due to the FILL_RETURN_BUFFER sequences). Importantly, ERAPS also improves cross-domain security by clearing the RAP in certain situations. Specifically, the RAP is cleared in response to actions that are typically tied to software context switching between tasks. Per the APM: The ERAPS feature eliminates the need to execute CALL instructions to clear the return address predictor in most cases. On processors that support ERAPS, return addresses from CALL instructions executed in host mode are not used in guest mode, and vice versa. Additionally, the return address predictor is cleared in all cases when the TLB is implicitly invalidated and in the following cases: • MOV CR3 instruction • INVPCID other than single address invalidation (operation type 0) ERAPS also allows CPUs to extends the size of the RSB/RAP from the older standard (of 32 entries) to a new size, enumerated in CPUID leaf 0x80000021:EBX bits 23:16 (64 entries in Zen5 CPUs). In hardware, ERAPS is always-on, when running in host context, the CPU uses the full RSB/RAP size without any software changes necessary. However, when running in guest context, the CPU utilizes the full size of the RSB/RAP if and only if the new ALLOW_LARGER_RAP flag is set in the VMCB; if the flag is not set, the CPU limits itself to the historical size of 32 entires. Requiring software to opt-in for guest usage of RAPs larger than 32 entries allows hypervisors, i.e. KVM, to emulate the aforementioned conditions in which the RAP is cleared as well as the guest/host split. E.g. if the CPU unconditionally used the full RAP for guests, failure to clear the RAP on transitions between L1 or L2, or on emulated guest TLB flushes, would expose the guest to RAP-based attacks as a guest without support for ERAPS wouldn't know that its FILL_RETURN_BUFFER sequence is insufficient. Address the ~two broad categories of ERAPS emulation, and advertise ERAPS support to userspace, along with the RAP size enumerated in CPUID. 1. Architectural RAP clearing: as above, CPUs with ERAPS clear RAP entries on several conditions, including CR3 updates. To handle scenarios where a relevant operation is handled in common code (emulation of INVPCID and to a lesser extent MOV CR3), piggyback VCPU_EXREG_CR3 and create an alias, VCPU_EXREG_ERAPS. SVM doesn't utilize CR3 dirty tracking, and so for all intents and purposes VCPU_EXREG_CR3 is unused. Aliasing VCPU_EXREG_ERAPS ensures that any flow that writes CR3 will also clear the guest's RAP, and allows common x86 to mark ERAPS vCPUs as needing a RAP clear without having to add a new request (or other mechanism). 2. Nested guests: the ERAPS feature adds host/guest tagging to entries in the RSB, but does not distinguish between the guest ASIDs. To prevent the case of an L2 guest poisoning the RSB to attack the L1 guest, the CPU exposes a new VMCB bit (CLEAR_RAP). The next VMRUN with a VMCB that has this bit set causes the CPU to flush the RSB before entering the guest context. Set the bit in VMCB01 after a nested #VMEXIT to ensure the next time the L1 guest runs, its RSB contents aren't polluted by the L2's contents. Similarly, before entry into a nested guest, set the bit for VMCB02, so that the L1 guest's RSB contents are not leaked/used in the L2 context. Enable ALLOW_LARGER_RAP (and emulate RAP clears) if and only if ERAPS is exposed to the guest. Enabling ALLOW_LARGER_RAP unconditionally wouldn't cause any functional issues, but ignoring userspace's (and L1's) desires would put KVM into a grey area, which is especially undesirable due to the potential security implications. E.g. if a use case wants to have L1 do manual RAP clearing even when ERAPS is present in hardware, enabling ALLOW_LARGER_RAP could result in L1 leaving stale entries in the RAP. ERAPS is documented in AMD APM Vol 2 (Pub 24593), in revisions 3.43 and later. Signed-off-by: Amit Shah <amit.shah@amd.com> Co-developed-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Amit Shah <amit.shah@amd.com> Link: https://patch.msgid.link/aR913X8EqO6meCqa@google.com Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
64e779e464 |
KVM: SVM: Don't allow L1 intercepts for instructions not advertised
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 1d1722e52fcd70deb53d8c192f958fe34be14f5e Author: Kevin Cheng <chengkev@google.com> Date: Mon Dec 15 19:25:10 2025 +0000 KVM: SVM: Don't allow L1 intercepts for instructions not advertised If a feature is not advertised in the guest's CPUID, prevent L1 from intercepting the unsupported instructions by clearing the corresponding intercept in KVM's cached vmcb12. When an L2 guest executes an instruction that is not advertised to L1, we expect a #UD exception to be injected by L0. However, the nested svm exit handler first checks if the instruction intercept is set in vmcb12, and if so, synthesizes an exit from L2 to L1 instead of a #UD exception. If a feature is not advertised, the L1 intercept should be ignored. While creating KVM's cached vmcb12, sanitize the intercepts for instructions that are not advertised in the guest CPUID. This effectively ignores the L1 intercept on nested vm exit handling. It also ignores the L1 intercept when computing the intercepts in vmcb02, so if L0 (for some reason) does not intercept the instruction, KVM won't intercept it at all. Signed-off-by: Kevin Cheng <chengkev@google.com> Co-developed-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20251215192510.2300816-1-chengkev@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
a4de34d3dc |
KVM: SVM: Add support for expedited writes to the fast MMIO bus
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 01cde4eaaecaf5df158234f0a52b4a1c55796858 Author: Sean Christopherson <seanjc@google.com> Date: Thu Nov 13 14:16:42 2025 -0800 KVM: SVM: Add support for expedited writes to the fast MMIO bus Wire up SVM's #NPF handler to fast MMIO. While SVM doesn't provide a dedicated exit reason, it's trivial to key off PFERR_RSVD_MASK. Like VMX, restrict the fast path to L1 to avoid having to deal with nGPA=>GPA translations. For simplicity, use the fast path if and only if the next RIP is known. While KVM could utilize EMULTYPE_SKIP, doing so would require additional logic to deal with SEV guests, e.g. to go down the slow path if the instruction buffer is empty. All modern CPUs support next RIP, and in practice the next RIP will be available for any guest fast path. Copy+paste the kvm_io_bus_write() + trace_kvm_fast_mmio() logic even though KVM would ideally provide a small helper, as such a helper would need to either be a macro or non-inline to avoid including trace.h in a header (trace.h must not be included by x86.c prior to CREATE_TRACE_POINTS being defined). Link: https://patch.msgid.link/20251113221642.1673023-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
539b08878c |
KVM: SVM: Rename "fault_address" to "gpa" in npf_interception()
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 737f2a382f89f2ff3d9d6a737004d97bfb98dc56 Author: Sean Christopherson <seanjc@google.com> Date: Thu Nov 13 14:16:41 2025 -0800 KVM: SVM: Rename "fault_address" to "gpa" in npf_interception() Rename "fault_address" to "gpa" in KVM's #NPF handler and track it as a gpa_t to more precisely document what type of address is being captured, and because "gpa" is much more succinct. No functional change intended. Link: https://patch.msgid.link/20251113221642.1673023-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
bd8272501a |
KVM: nSVM: Remove a user-triggerable WARN on nested_svm_load_cr3() succeeding
JIRA: https://issues.redhat.com/browse/RHEL-151869
commit fc3ba56385d03501eb582e4b86691ba378e556f9
Author: Sean Christopherson <seanjc@google.com>
Date: Tue Dec 16 08:17:54 2025 -0800
KVM: nSVM: Remove a user-triggerable WARN on nested_svm_load_cr3() succeeding
Drop the WARN in svm_set_nested_state() on nested_svm_load_cr3() failing
as it is trivially easy to trigger from userspace by modifying CPUID after
loading CR3. E.g. modifying the state restoration selftest like so:
--- tools/testing/selftests/kvm/x86/state_test.c
+++ tools/testing/selftests/kvm/x86/state_test.c
@@ -280,7 +280,16 @@ int main(int argc, char *argv[])
/* Restore state in a new VM. */
vcpu = vm_recreate_with_one_vcpu(vm);
- vcpu_load_state(vcpu, state);
+
+ if (stage == 4) {
+ state->sregs.cr3 = BIT(44);
+ vcpu_load_state(vcpu, state);
+
+ vcpu_set_cpuid_property(vcpu, X86_PROPERTY_MAX_PHY_ADDR, 36);
+ __vcpu_nested_state_set(vcpu, &state->nested);
+ } else {
+ vcpu_load_state(vcpu, state);
+ }
/*
* Restore XSAVE state in a dummy vCPU, first without doing
generates:
WARNING: CPU: 30 PID: 938 at arch/x86/kvm/svm/nested.c:1877 svm_set_nested_state+0x34a/0x360 [kvm_amd]
Modules linked in: kvm_amd kvm irqbypass [last unloaded: kvm]
CPU: 30 UID: 1000 PID: 938 Comm: state_test Tainted: G W 6.18.0-rc7-58e10b63777d-next-vm
Tainted: [W]=WARN
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
RIP: 0010:svm_set_nested_state+0x34a/0x360 [kvm_amd]
Call Trace:
<TASK>
kvm_arch_vcpu_ioctl+0xf33/0x1700 [kvm]
kvm_vcpu_ioctl+0x4e6/0x8f0 [kvm]
__x64_sys_ioctl+0x8f/0xd0
do_syscall_64+0x61/0xad0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
Simply delete the WARN instead of trying to prevent userspace from shoving
"illegal" state into CR3. For better or worse, KVM's ABI allows userspace
to set CPUID after SREGS, and vice versa, and KVM is very permissive when
it comes to guest CPUID. I.e. attempting to enforce the virtual CPU model
when setting CPUID could break userspace. Given that the WARN doesn't
provide any meaningful protection for KVM or benefit for userspace, simply
drop it even though the odds of breaking userspace are minuscule.
Opportunistically delete a spurious newline.
Fixes:
|
||
|
Maxim Levitsky
|
8bc0465314 |
KVM: x86: Don't read guest CR3 when doing async pf while the MMU is direct
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 57a7b47ab30f6201769988392dc8b1c0822a3369 Author: Xiaoyao Li <xiaoyao.li@intel.com> Date: Fri Dec 12 21:50:51 2025 +0800 KVM: x86: Don't read guest CR3 when doing async pf while the MMU is direct Don't read guest CR3 in kvm_arch_setup_async_pf() if the MMU is direct and use INVALID_GPA instead. When KVM tries to perform the host-only async page fault for the shared memory of TDX guests, the following WARNING is triggered: WARNING: CPU: 1 PID: 90922 at arch/x86/kvm/vmx/main.c:483 vt_cache_reg+0x16/0x20 Call Trace: __kvm_mmu_faultin_pfn kvm_mmu_faultin_pfn kvm_tdp_page_fault kvm_mmu_do_page_fault kvm_mmu_page_fault tdx_handle_ept_violation This WARNING is triggered when calling kvm_mmu_get_guest_pgd() to cache the guest CR3 in kvm_arch_setup_async_pf() for later use in kvm_arch_async_page_ready() to determine if it's possible to fix the page fault in the current vCPU context to save one VM exit. However, when guest state is protected, KVM cannot read the guest CR3. Since protected guests aren't compatible with shadow paging, i.e, they must use direct MMU, avoid calling kvm_mmu_get_guest_pgd() to read guest CR3 when the MMU is direct and use INVALID_GPA instead. Note that for protected guests mmu->root_role.direct is always true, so that kvm_mmu_get_guest_pgd() in kvm_arch_async_page_ready() won't be reached. Reported-by: Farrah Chen <farrah.chen@intel.com> Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://patch.msgid.link/20251212135051.2155280-1-xiaoyao.li@intel.com [sean: explicitly cast to "unsigned long" to make 32-bit builds happy] Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
d44073a96c |
KVM: selftests: Rename vm_get_page_table_entry() to vm_get_pte()
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit e353850499c717f1f984f7c208f49a8618beff2f Author: Sean Christopherson <seanjc@google.com> Date: Tue Dec 30 15:01:49 2025 -0800 KVM: selftests: Rename vm_get_page_table_entry() to vm_get_pte() Shorten the API to get a PTE as the "PTE" acronym is ubiquitous, and the "page table entry" makes it unnecessarily difficult to quickly understand what callers are doing. No functional change intended. Reviewed-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20251230230150.4150236-21-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
f33ef75100 |
KVM: selftests: Extend memstress to run on nested SVM
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 59eef1a47b8c264d09ee84c909a1da60b4e70bd7 Author: Yosry Ahmed <yosry.ahmed@linux.dev> Date: Tue Dec 30 15:01:48 2025 -0800 KVM: selftests: Extend memstress to run on nested SVM Add L1 SVM code and generalize the setup code to work for both VMX and SVM. This allows running 'dirty_log_perf_test -n' on AMD CPUs. Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20251230230150.4150236-20-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
6c175bfe7b |
KVM: selftests: Extend vmx_dirty_log_test to cover SVM
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 6794d916f87e0a6cd51a3d8c2c0e6ffd48fa7a79 Author: Yosry Ahmed <yosry.ahmed@linux.dev> Date: Tue Dec 30 15:01:47 2025 -0800 KVM: selftests: Extend vmx_dirty_log_test to cover SVM Generalize the code in vmx_dirty_log_test.c by adding SVM-specific L1 code, doing some renaming (e.g. EPT -> TDP), and having setup code for both SVM and VMX in test_dirty_log(). Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20251230230150.4150236-19-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
4001751038 |
KVM: selftests: Set the user bit on nested NPT PTEs
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 251e4849a79b258fd3e889ff095ba083ce301c13 Author: Yosry Ahmed <yosry.ahmed@linux.dev> Date: Tue Dec 30 15:01:46 2025 -0800 KVM: selftests: Set the user bit on nested NPT PTEs According to the APM, NPT walks are treated as user accesses. In preparation for supporting NPT mappings, set the 'user' bit on NPTs by adding a mask of bits to always be set on PTEs in kvm_mmu. Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20251230230150.4150236-18-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
f9b633f178 |
KVM: selftests: Add support for nested NPTs
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 753c0d5a507b939d6efc60c7b437d5330880cce3 Author: Yosry Ahmed <yosry.ahmed@linux.dev> Date: Tue Dec 30 15:01:45 2025 -0800 KVM: selftests: Add support for nested NPTs Implement nCR3 and NPT initialization functions, similar to the EPT equivalents, and create common TDP helpers for enablement checking and initialization. Enable NPT for nested guests by default if the TDP MMU was initialized, similar to VMX. Reuse the PTE masks from the main MMU in the NPT MMU, except for the C and S bits related to confidential VMs. Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20251230230150.4150236-17-seanjc@google.com [sean: apply Yosry's fixup for ncr3_gpa] Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
bc760cee08 |
KVM: selftests: Allow kvm_cpu_has_ept() to be called on AMD CPUs
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 9cb1944f6bf09ecebcc7609f35178b85aa26f165 Author: Yosry Ahmed <yosry.ahmed@linux.dev> Date: Tue Dec 30 15:01:44 2025 -0800 KVM: selftests: Allow kvm_cpu_has_ept() to be called on AMD CPUs In preparation for generalizing the nested dirty logging test, checking if either EPT or NPT is enabled will be needed. To avoid needing to gate the kvm_cpu_has_ept() call by the CPU type, make sure the function returns false if VMX is not available instead of trying to read VMX-only MSRs. No functional change intended. Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20251230230150.4150236-16-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
70fda8507e |
KVM: selftests: Move TDP mapping functions outside of vmx.c
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 07676c04bd753f32a9fe2f247b0ba2d213dd7a99 Author: Sean Christopherson <seanjc@google.com> Date: Tue Dec 30 15:01:43 2025 -0800 KVM: selftests: Move TDP mapping functions outside of vmx.c Now that the functions are no longer VMX-specific, move them to processor.c. Do a minor comment tweak replacing 'EPT' with 'TDP'. No functional change intended. Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20251230230150.4150236-15-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
62346e6bd7 |
KVM: selftests: Reuse virt mapping functions for nested EPTs
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 508d1cc3ca0ac428b1d5d614519bc497868c2e9f Author: Yosry Ahmed <yosry.ahmed@linux.dev> Date: Tue Dec 30 15:01:42 2025 -0800 KVM: selftests: Reuse virt mapping functions for nested EPTs Rework tdp_map() and friends to use __virt_pg_map() and drop the custom EPT code in __tdp_pg_map() and tdp_create_pte(). The EPT code and __virt_pg_map() are practically identical, the main differences are: - EPT uses the EPT struct overlay instead of the PTE masks. - EPT always assumes 4-level EPTs. To reuse __virt_pg_map(), extend the PTE masks to work with EPT's RWX and X-only capabilities, and provide a tdp_mmu_init() API so that EPT can pass in the EPT PTE masks along with the root page level (which is currently hardcoded to '4'). Don't reuse KVM's insane overloading of the USER bit for EPT_R as there's no reason to multiplex bits in the selftests, e.g. selftests aren't trying to shadow guest PTEs and thus don't care about funnelling protections into a common permissions check. Another benefit of reusing the code is having separate handling for upper-level PTEs vs 4K PTEs, which avoids some quirks like setting the large bit on a 4K PTE in the EPTs. For all intents and purposes, no functional change intended. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev> Co-developed-by: Sean Christopherson <seanjc@google.com> Link: https://patch.msgid.link/20251230230150.4150236-14-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
4dae8d5393 |
KVM: selftests: Add a stage-2 MMU instance to kvm_vm
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit 8296b16c0a2ba018c3235db5325d679e603899d6 Author: Sean Christopherson <seanjc@google.com> Date: Tue Dec 30 15:01:41 2025 -0800 KVM: selftests: Add a stage-2 MMU instance to kvm_vm Add a stage-2 MMU instance so that architectures that support nested virtualization (more specifically, nested stage-2 page tables) can create and track stage-2 page tables for running L2 guests. Plumb the structure into common code to avoid cyclical dependencies, and to provide some line of sight to having common APIs for creating stage-2 mappings. As a bonus, putting the member in common code justifies using stage2_mmu instead of tdp_mmu for x86. Reviewed-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20251230230150.4150236-13-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |
||
|
Maxim Levitsky
|
6ae17af5ce |
KVM: selftests: Stop passing VMX metadata to TDP mapping functions
JIRA: https://issues.redhat.com/browse/RHEL-151869 commit e40e72fec0dea9ac55aea84a0d76ccb7d7f32204 Author: Yosry Ahmed <yosry.ahmed@linux.dev> Date: Tue Dec 30 15:01:40 2025 -0800 KVM: selftests: Stop passing VMX metadata to TDP mapping functions The root GPA is now retrieved from the nested MMU, stop passing VMX metadata. This is in preparation for making these functions work for NPTs as well. Opportunistically drop tdp_pg_map() since it's unused. No functional change intended. Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20251230230150.4150236-12-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> |