summaryrefslogtreecommitdiff
path: root/tools/testing/selftests/kvm/include/x86
AgeCommit message (Collapse)Author
14 daysMerge tag 'kvm-x86-selftests-7.4' of https://github.com/kvm-x86/linux into HEADPaolo Bonzini
KVM selftests changes and a few KVM x86 fixes for 7.4 - Fix emulation of VMPTRST and VMPTRLD when eVMCS is in-use to match real Hyper-V's behavior. - Saturate L2's TSC frequency if stacking L1 and L2 scaling multipliers exceeds what hardware supports, as attempting to run L2 with an illegal multiplier will either cause VM-Entry to fail (VMX) or trigger a #GP when writing MSR_AMD64_TSC_RATIO (SVM). The #GP is thankfully benign in the grand scheme as even "unsafe" WRMSRs have exception fixup. - Rework KVM selftest's handling of memory regions so that PPC can force its page table allocations to be naturally aligned. - Clean up selftest's VMX instruction helpers, and drop an absurd number of completely useless return values, e.g. functions that unconditionally return %true and then have every caller assert success. - Add selftests support for Zhaoxin CPUs. - Overhaul the TSC scaling test to add a regression test for the saturation behavior, and to increase its coverage in general. - Fix selftests usage various NUMA syscalls to account for an undocumented, but known since 2007, off-by-one kernel bug. Add helpers to try and avoid re-introducing the same flaws in the future. - Automatically run xAPIC IPI migration test (between NUMA nodes) when possible, as the entire point of the test is verify KVM's handling of page migration of the APIC backing page. - Misc cleanups.
2026-09-30KVM: selftests: Add coverage for the EFER_LMSLE_MBZ defeatureJim Mattson
Add coverage for KVM's virtualization of EFER_LMSLE_MBZ, CPUID.80000008H:EBX[bit 20], which is set when the CPU does *not* support long mode segment limits. Verify that KVM's enumeration of the defeature matches the expectation derived from hardware plus kvm_amd's "nested" module param, so that the assertion doesn't compare KVM's enumeration against itself, and that WRMSR(EFER), nested VMRUN, and KVM_SET_SREGS reject EFER.LMSLE=1 if and only if guest CPUID enumerates the defeature. Also verify that host-initiated KVM_SET_MSRS is exempt from the check, as host-initiated writes skip guest CPUID checks so that userspace can set MSRs before it sets guest CPUID. Extend svm_nested_efer_test rather than add yet another test binary for a single CPUID bit; the test already has the L1/L2 harness needed to exercise EFER.LMSLE. Note, only a CPU that supports LMSLE, i.e. Rome and earlier, exercises the emulation path; elsewhere KVM enumerates the defeature straight from hardware. Opportunistically drop the unnecessary #include of vmx.h. Assisted-by: LLM Signed-off-by: Jim Mattson <jmattson@google.com> [sean: drop specific APM volume references, use common "nested" getter] Link: https://patch.msgid.link/20260930212114.3500045-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-30KVM: selftests: Add module param API to check if nested virtualization is ↵Sean Christopherson
enabled Add an API to check if the nested virtualization module param is enabled, e.g. so that tests can verify KVM's own enumeration of the corresponding CPU feature. Provide a big warning above the API to make it as obvious as possible clear that tests should use "kvm_cpu_has(X86_FEATURE_VMX) || kvm_cpu_has(X86_FEATURE_SVM)" when checking for nested virtualization. It doesn't really matter which method tests use, as KVM is supposed to keep "nested" synchronized with VMX/SVM enumeration, but make the comment super scary to try and prevent KVM selftests from having two different ways of doing the same thing. Note, the bool vs. int mess is intentional, because KVM's params are terrible. kvm_amd.ko provides an "int", while kvm_intel.ko provides a "bool". Link: https://patch.msgid.link/20260930212114.3500045-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-29KVM: selftests: Delete the declaration of vcpu_set_cpuid_maxphyaddr()Gokul K
vcpu_set_cpuid_maxphyaddr() is declared in include/x86/processor.h and defined nowhere. The declaration is the only mention of the name in tools/testing/selftests, so nothing has ever been able to call it. No Fixes: tag: a prototype for a function that does not exist cannot have regressed anything, and there is nothing to backport. No functional change intended. Signed-off-by: Gokul K <gokul02k@gmail.com> Link: https://patch.msgid.link/20260918113631.634233-3-gokul02k@gmail.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: selftests: Check for APIC access virtualization support in said testFrank Zhu
Not all CPUs that support VMX necessarily support the "virtualize APIC accesses" secondary processor-based VM-execution control. For example, some Zhaoxin CPUs lack this feature. Add a capability check before running the test to properly skip on unsupported hardware instead of failing. Carve out the guts of kvm_cpu_has_ept() into a generic helper and use said helper to provide kvm_cpu_has_vmx_apic_access_virt(). Signed-off-by: Frank Zhu <frankzhu@zhaoxin.com> Link: https://patch.msgid.link/20260910115414.3015260-10-ewanhai-oc@zhaoxin.com [sean: add a helper instead of copy+pasting kvm_cpu_has_ept()] Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: selftests: Use host_cpu_is_intel_compatible for mediated PMUFrank Zhu
kvm_is_mediated_pmu_enabled() returns kvm_amd's enable_mediated_pmu module parameter unless the host CPU is Intel. Zhaoxin CPUs implement VMX-compatible virtualization and are handled by KVM's VMX backend, so on Zhaoxin hosts the helper wrongly reports kvm_amd's parameter. Gate the check on host_cpu_is_intel_compatible so that Zhaoxin CPUs, like Intel CPUs, query kvm_intel's enable_mediated_pmu instead. This does not change behavior on Intel, and AMD and other non-Intel- compatible CPUs still fall back to kvm_amd's parameter. Signed-off-by: Frank Zhu <frankzhu@zhaoxin.com> Link: https://patch.msgid.link/20260910115414.3015260-3-ewanhai-oc@zhaoxin.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: selftests: Add Zhaoxin CPU detection supportFrank Zhu
Add helpers to detect Zhaoxin CPUs using the "CentaurHauls" and " Shanghai " vendor strings. KVM handles Zhaoxin CPUs with its VMX backend. Add host_cpu_is_intel_compatible for selftests that exercise behavior shared by Intel and Zhaoxin CPUs, while retaining host_cpu_is_zhaoxin for Zhaoxin-specific behavior. Signed-off-by: Frank Zhu <frankzhu@zhaoxin.com> Link: https://patch.msgid.link/20260910115414.3015260-2-ewanhai-oc@zhaoxin.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: selftests: Always assert that vmreadz() succeedsSean Christopherson
Rename vmreadz() => vmread() (and vmread() => __vmread()) and have it assert success instead of returning garbage on failure. While the eVMCS path avoids clobbering *value on failure, the VMREAD path unconditionally stores tmp to *value, without ever zeroing tmp. I.e. if VMREAD did fail, *value would be loaded with random stack data, not '0'. An audit of the code confirms that nothing is actually relying on vmreadz() to zero the result on failure, as all paths either check for a non-zero value, propagate the result into vmwrite(), or guard the vmread() with a pre-check that the field exists. Opportunistically fix the bug in what is now __vmread(), so that the code isn't consuming uninitialized stack data. Begrudgingly keep zeroing value in vmread(), as gcc-15 at least isn't smart enough to figure out that value won't be used uninitialized (though to be fair, strictly speaking it isn't actually unreachable code). Link: https://patch.msgid.link/20260904002423.3154436-18-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: selftests: Always assert that vmwrite() succeedsSean Christopherson
Assert that vmwrite() succeeds instead of forcing all callers to do the same (or as is much more common, ignoring VM-Fail and likely letting the test fail in weird ways), opportunistically provide a more verbose error message on failure. All usage of vmwrite() "guarantees" success, either because the field in question is unconditionally emulated by KVM, by virtue of earlier support checks, or by falling over (later in the test) if the VMWRITE fails. Cc: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260904002423.3154436-17-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: selftests: Add __vmwrite() and use it when initializing optional fields.Sean Christopherson
Add __vmwrite() in anticipation of having vmwrite() assert success, and use the "failure allowed" version in the common VMCS setup code, which is the only code that wants to write fields that may or may not exist (although arguably the code should check if the field exists instead of blindly writing). E.g. When doing initial configuration of a VMCS, the core library doesn't want to assume secondary controls are supported, and so blindly does a VMWRITE and pivots on success/failure. All usage of vmwrite() outside of common setup already asserts success, or 100% relies on VMWRITE succeeding in order for the test to function correctly. No functional change intended. Link: https://patch.msgid.link/20260904002423.3154436-16-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: selftests: Assert success in vmlaunch() and vmresume()Sean Christopherson
Assert success in the "outer" APIs for VMLAUNCH and VMRESUME to dedup a pile of code, and switch to the double-underscores versions as necessary, to make it more obvious which paths expect VM-Enter *failure*. Link: https://patch.msgid.link/20260904002423.3154436-15-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: selftests: Dedup assembly code for VMLAUNCH and VMRESUMESean Christopherson
Dedup the assembly code for VMLAUNCH vs. VMRESUME, for both architectural VMCS and eVMCS, as the difference is literally only the actual VM-Enter instruction for VMLAUNCH vs. VMRESUME, and VMWRITE vs. MOV for VMCS vs. eVMCS. Opportunistically place the implementations in vmx.c so that the lengthy sequence (~580 bytes of code) aren't inlined for every single VM-Enter. 000000000041b910 <__vmlaunch>: 41b910: 80 3d 61 5e 10 00 00 cmpb $0x0,0x105e61(%rip) # 521778 <enable_evmcs> 41b917: 0f 85 13 01 00 00 jne 41ba30 <__vmlaunch+0x120> 41b91d: ba 14 6c 00 00 mov $0x6c14,%edx 41b922: b9 16 6c 00 00 mov $0x6c16,%ecx 41b927: 6a 00 push $0x0 41b929: 0f 79 d4 vmwrite %rsp,%rdx 41b92c: 48 8d 05 82 00 00 00 lea 0x82(%rip),%rax # 41b9b5 <__vmlaunch+0xa5> 41b933: 0f 79 c8 vmwrite %rax,%rcx <xchg GPRs> 41b9ae: 0f 01 c2 vmlaunch 41b9b1: 48 ff 04 24 incq (%rsp) <xchg GPRs> 41ba2d: 58 pop %rax 41ba2e: c3 ret 41ba2f: 90 nop 41ba30: 48 8b 35 39 5d 10 00 mov 0x105d39(%rip),%rsi # 521770 <current_evmcs> 41ba37: c7 86 38 03 00 00 00 00 00 00 movl $0x0,0x338(%rsi) 41ba41: 6a 00 push $0x0 41ba43: 48 89 a6 68 02 00 00 mov %rsp,0x268(%rsi) 41ba4a: 48 8d 05 83 00 00 00 lea 0x83(%rip),%rax # 41bad4 <__vmlaunch+0x1c4> 41ba51: 48 89 46 50 mov %rax,0x50(%rsi) <xchg GPRs> 41bacd: 0f 01 c2 vmlaunch 41bad0: 48 ff 04 24 incq (%rsp) <xchg GPRs> 41bb4c: 58 pop %rax 41bb4d: c3 ret No functional change intended (though the code generation will be quite different). Cc: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260904002423.3154436-14-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: selftests: Drop dead return code from evmcs_vmptrld() and load_evmcs()Sean Christopherson
Drop the return codes from evmcs_vmptrld() and load_evmcs() as they are hardcoded to return '0' and "true" respectively. No functional change intended. Link: https://patch.msgid.link/20260904002423.3154436-13-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: selftests: Add macros to handle simple VMX instructionsSean Christopherson
Add macros to build helpers for VMXON, VMPTRLD, and VMCLEAR, i.e. the VMX instructions that take a VMCS address as input, and don't have outputs. Getting the params right is annoying, especially when using KVM_ASM_SAFE(). As a bonus, this adds non-asserting double-underscores versions of VMXON and VMCLEAR for "free". Link: https://patch.msgid.link/20260904002423.3154436-12-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: selftests: Drop useless return code from load_vmcs()Sean Christopherson
Now that load_vmcs() either asserts or returns success, drop the return code and the many asserts in its callers. Link: https://patch.msgid.link/20260904002423.3154436-11-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: selftests: Always assert that vmptrld() succeedsSean Christopherson
Assert that vmptrld() succeeds instead of forcing all callers to do the same, and opportunistically provide a macro to print (hopefully) useful information on VMX instruction failures. Leave load_vmcs() as-is for the moment to minimize the amount of churn since the vmptrld() changes aren't completely trivial. Link: https://patch.msgid.link/20260904002423.3154436-10-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: selftests: Always assert that vmclear() succeedsSean Christopherson
Continue removing dead error "handling", and assert that VMCLEAR succeeds instead of forcing callers of load_vmcs() to assert success. For all intents and purposes, no functional change intended. Link: https://patch.msgid.link/20260904002423.3154436-9-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: selftests: Always assert that vmxon() and prepare_for_vmx_operation() ↵Sean Christopherson
succeed Assert that vmxon() succeeds, and by extension prepare_for_vmx_operation(). Forcing every caller to assert that a core preparation helper succeeds is absurd and generates hard-to-read code. For all intents and purposes, no functional change intended. Link: https://patch.msgid.link/20260904002423.3154436-8-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: selftests: Assert success in vmptrst(), kill off vmptrstz()Sean Christopherson
Assert success in vmptrst() instead of punting to the caller, as literally every user expects VMPTRST to succeed (and because '0' is a valid physical address). Link: https://patch.msgid.link/20260904002423.3154436-7-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: selftests: Check VMPTRLD with active eVMCSVitaly Kuznetsov
Check that VMPTRLD when eVMCS is active results in #UD. This matches genuine Hyper-V's behavior. Use KVM_ASM_SAFE framework to handle #UD from VMPTRLD. Unfortunately, the same trick cannot be applied to the existing #UD check on VMLAUNCH as VMLAUNCH clobbers all registers which KVM_ASM_SAFE depends on. Keep VMLAUNCH handling separately. Deliberately use a double-underscores prefix instead of a "safe" postfix for the helper, to communicate that the inner/outer helpers handle more than just exceptions, they also handle VM-Fail conditions. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> [sean: use __ instead of _safe] Link: https://patch.msgid.link/20260904002423.3154436-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: selftests: Adapt to the updated VMPTRST behavior when eVMCS is usedVitaly Kuznetsov
Previously, VMPTRST was forbidden with eVMCS and selftests were mocking the correct behavior in vmptrst() by returning enlightened vmptr directly. Since KVM's behavior has changed to match genuine Hyper-V, adjust evmcs test accordingly. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Link: https://patch.msgid.link/20260904002423.3154436-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: selftests: Don't clobber RFLAGS in happy path of __KVM_ASM_SAFE()Sean Christopherson
Use a straight MOV instead of an XOR to zero R9 in the non-faulting path of __KVM_ASM_SAFE() so as not to clobber RFLAGS. XOR generates smaller code, but optimizing performance by minimizing the code footprint is just about the last thing that KVM selftests care about. The bug is relatively benign in the current code base, e.g. it marginally degrades the coverage in the fastops test, but otherwise does no harm. But the bug will become actively problematic if/when the "safe assembly" macros are used for instructions that communicate results via RFLAGS, e.g. for VMX instructions, which signal failure via RFLAGS.CF and RFLAGS.ZF. Opportunistically use R9D instead of the full R9, as bits 63:32 of GPRs are zeroed on writes to bit 31:0. Reported-by: Sashiko Bot <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260818165258.2613603-5-vkuznets@redhat.com Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Link: https://patch.msgid.link/20260904002423.3154436-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11KVM: selftests: Add TEST_EXTRA memory region type for "special" memslotsSean Christopherson
And another memory region type to deal with extra, one-off memory regions, and use the new type to manage x86's SMRAM memslot, as another step towards taking the region type instead of the raw memslot in the physical page allocator APIs. Alternatively, SMRAM setup could simply use the quad-underscore API to continue passing in the memslot, but a surprising number of tests use an "extra" memslot for a variety of reasons. I.e. allocating memory from one (and exactly one) extra memslot isn't all that rare, and so should be treated as normal behavior, not as something extraordinary, as quad-underscore functions typically suggest. Opportunistically add comments to document the intended usage of the types, as the difference between DATA, TEST_DATA, and TEST_EXTRA in particular isn't exactly obvious. Tested-by: Itaru Kitayama <itaru.kitayama@fujitsu.com> Tested-by: Itaru Kitayam <itaru.kitayama@fujitsu.com> Link: https://patch.msgid.link/20260902164123.2546762-14-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-08-18Merge tag 'kvm-x86-misc-7.3' of https://github.com/kvm-x86/linux into HEADPaolo Bonzini
KVM x86 misc changes for 7.3 - Fix VPID virtualization bugs where KVM would fail to flush hardware TLBs. - Harden the SNP and TDX "populate" ioctls against bad input, and to prepare for supporting in-place private<=>shared conversion. - Fix a variety of #DB priority bugs. - Fix a class of races related to enabling Hyper-V emulation on a vCPU after the vCPU is visible to the rest of KVM. - Use static calls for nested virtualization ops. - Move more KVM-internal code out of x86's kvm_host.h. - Enumerate support for a variety of Zhaoxin instructions that don't require explicit virtualization. - Fix missing EFER validation bugs, including in the KVM_SET_SREGS* path. - Harden kvm_vcpu_map() against double-mapping and thus leaking references. - Misc fixes and cleanups, e.g. for largely benign syzkaller splats.
2026-08-18Merge tag 'kvm-x86-selftests2-7.3' of https://github.com/kvm-x86/linux into HEADPaolo Bonzini
KVM selftests changes for 7.3, part 2 - Fix several issues with seeding KVM's pRNG, and rework the pRNG APIs to that the pRNG can be sanely used in host code, not just guest code. - Add an IRQ test to validate virtual IRQ deliverty for IRQs wired up via KVM_IRQFD + KVM_SET_GSI_ROUTING, with optional support for triggering IRQs via writes to an assigned VFIO device. - Add syscall wrappers to assert success on a variety of pthreads and CPU affinity APIs. - Set vCPU pthread affinity as early as possible to reduce contention issues that were surfaced by PREEMPT_LAZY, which result in runtimes of over a minute on large hosts, versus the expected ~5 seconds. - Rework the PMU counters test to run each testcase using a single VM with many vCPUs for each sub-testcase, instead of using a unique VM for each sub-testcase. This cuts the runtime by ~20x.
2026-07-29KVM: selftests: Trigger L2->L1 exits stress save+restore and #PF testYosry Ahmed
Extend the testing coverage in L2 by forcing a nested VM-Exit from L2 to L1 right after restore on every other iteration. Forcing a nested VM-Exit while L0 has control (e.g. without explicitly running L2 and making a hypercall) is valuable, as it often happens during live migration (e.g. L1 timer interrupt fires by the time the VM lands on the destination). To force the nested VM-Exit inject a #UD in to the saved vCPU state, and intercept #UD from L1. With this change, the test reliably reproduces the CR2 bug fixed by commit 5c247d08bc81 ("KVM: nSVM: Use vcpu->arch.cr2 when updating vmcb12 on nested #VMEXIT") -- at least on Milan, Genoa, and Turin CPUs. Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260728174232.2423257-14-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-29KVM: selftests: Add basic stress test for save+restore and #PF handlingYosry Ahmed
Add a basic stress test for handling #PFs in a guest while the host is doing save+restore cycles. The guest periodically accesses non-present memory causing a #PF, and the #PF handler walks the page tables and updates the PTE to be present, like a proper #PF handler. After every access (and #PF), the guest triggers a sync and the test performs save+restore of the VM. This is not very meaningful as save+restore are performed after the access and #PF handling complete, but following changes will change that. Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260728174232.2423257-11-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-29KVM: selftests: Expose PTE masks to guests as part of an MMUYosry Ahmed
Expose a guest_mmu to the guest to allow guest code to use the PTE masks for page table manipulation. Since guest page tables are not mapped in the guest by default, zero the PGD in guest_mmu in an attempt to make it more difficult for new tests to shoot themselves in the foot and assume that page tables can be immediately used by guest code. Ultimately, guest code can read CR3 any way, so guest_mmu.pgd doesn't add a lot of value. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260728174232.2423257-9-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-29KVM: selftests: Reuse GPR switching logic for nVMXYosry Ahmed
Reuse the GPR switching logic for nVMX by defining VMX_SWITCH_GPRS_ASM, which is essentially the same as SVM_SWITCH_GPRS_ASM but also switches RAX and doesn't switch RFLAGS, replacing the push/pop of a subset of the registers. The long clobber list of registers is no longer needed as registers are saved and restored appropriately (and not clobbered by L2). Define VMX_SWITCH_GPRS_ASM before including evmcs.h, such that it can be used by evmcs_vmlaunch() and evmcs_vmresume(). This replaces the apparently thread-safe push/pop sequence with the global GPR switching logic used by SVM, which isn't thread-safe at all. However this is still an improvement because: - The VMX logic is half-baked and prompts the UCALL clobber hack as it doesn't properly save/restore everything. Reusing the GPR switching logic used by SVM allows for dropping that hack. - Hitting a problem due to half-baked GPR save/restore logic is arguably more likely than thread-safety. Evidently, adding more involved stress tests fails on VMX with the existing push/pop sequence. OTOH, there are no known failures on SVM due to lack of thread-safety fo save/restore. Only one test currently uses more than one vCPU with nested (the memstress test). The logical next step is to move the guest_regs to be per-vCPU, making it thread-safe for both VMX and SVM in a proper way. Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260728174232.2423257-6-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-29KVM: selftests: Handle rflags save/restore for SVM in guest_regsYosry Ahmed
Instead of handling rflags separately, add it to guest_regs. No functional change intended. Assisted-by: Gemini:Gemini-Next Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260728174232.2423257-5-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-29KVM: selftests: Rework GPR registers switching for SVM (and fix offsets)Yosry Ahmed
The assembly code defined by SAVE_GPR_C uses the wrong offsets for some registers in guest_regs. For example, the offset of RCX should be 0x08 not 0x10. Also, the last offset in the struct (R15) is 0x78, not 0x80, so the code actually saves and restore beyond the end of gpr64_regs. Eliminate hardcoded offsets by dynamically generating offsets using offset_of() and using macros to pass the offsets to assembly as asm constraints. To avoid register conflicts in inline assembly (since almost all GPRs are context-switched), access guest_regs via absolute symbol addressing (guest_regs + offset) rather than using a base register which could get overwritten mid-assembly. While at it, rename SAVE_GPR_C and LOAD_GPR_C to a single macro, SVM_SWITCH_GPRS_ASM, rename gpr64_regs to guest_regs, and expose it in processor.h (in preparation for reusing it for VMX). Assisted-by: Gemini:Gemini-Next Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260728174232.2423257-4-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-27KVM: selftests: Extend set_sregs test to cover EFERYosry Ahmed
Extend the set_sregs test to cover various bits in EFER. Update TEST_INVALID_CR_BIT() to operate on EFER as well as CRx (and rename it accordingly). Add test cases to check that EFER bits are disallowed without the relevant CPUID enablement. Assisted-by: Gemini:unknown-version Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260713180153.2728382-3-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Rename guest_rng to kvm_rngJosh Hilke
Rename functions prefixed with 'guest_random_' to 'kvm_random_' and the global random state variable 'guest_rng' to 'kvm_rng', as the pRNG isn't strictly limited to guest code. This will allow using the pRNG in host code without creating confusing/misleading function calls. No functional changes are intended. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-17KVM: selftests: Add svm_pmu_host_guest_test for Host-Only/Guest-Only bitsJim Mattson
Add a selftest to verify KVM correctly virtualizes the AMD PMU Host-Only (bit 41) and Guest-Only (bit 40) event selector bits across all relevant SVM state transitions. The test programs 4 PMCs simultaneously with all combinations of the Host-Only and Guest-Only bits, then verifies correct counting behavior with EFER.SVME clear and set, as well as in host mode and guest mode. The test also verifies that updating Host-Only / Guest-Only bits for a PMC works as intended, and that event filtering is still respected. Signed-off-by: Jim Mattson <jmattson@google.com> Co-developed-by: Yosry Ahmed <yosry@kernel.org> Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260610003030.2957261-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-17KVM: selftests: Add a helper to query enable_mediated_pmu module paramSean Christopherson
Add a utility to check whether or not the mediated PMU is enabled, pivoting on Intel vs. AMD since the module param is defined by vendor code. Link: https://patch.msgid.link/20260610003030.2957261-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-17KVM: selftests: Drop L1-provided stacks for L2 guests on x86Yosry Ahmed
Now that a dedicated page is allocated for L2's stack and stuffed in RSP, the L1-provided stack is unused. Drop the stacks allocated by L1 guest code for L2 in all x86 tests. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260610003030.2957261-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-17KVM: selftests: Allocate a dedicated guest page for x86 L2 guest stackYosry Ahmed
Instead of relying on the L1-provided stack for L2, which is usually an array on L1's own stack, allocate a dedicated page of VM memory for the L2 stack in vcpu_alloc_{vmx/svm}() and use that as L2's RSP in the VMCS/VMCB instead of the L1-provided value. Most L1 guest code does not do anything with the L2 stack other than stuff it in RSP, so this change is transparent and the L1-provided stack is silently ignored. The only exception is memstress nested L1 code which puts the vCPU index on L2's stack, so update this code to use the newly allocated stack. L1-provided stacks will be dropped and cleaned up separately. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260610003030.2957261-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-06-12Merge tag 'kvm-x86-sev-7.2' of https://github.com/kvm-x86/linux into HEADPaolo Bonzini
KVM SEV changes for 7.2 - Don't advertise support for unusuable VM types, and account for VM types that are disabled by firmware, e.g. to mitigate security vulnerabilities. - Rewrite the SEV {en,de}crypt debug ioctls as they were riddle with bugs and unnecessarily complicated, and add comprehensive tests. - Clean up and deduplicate the SEV page pinning code. - Fix minor goofs related to writing back CPUID information after firmware rejects a CPUID page for an SNP vCPU.
2026-05-27KVM: selftests: Update hwcr_msr_test for CPUID faulting bitJim Mattson
Add BIT_ULL(35) (CpuidUserDis) to the valid mask in hwcr_msr_test, now that KVM accepts writes to this bit when the guest CPUID advertises CpuidUserDis. Signed-off-by: Jim Mattson <jmattson@google.com> Link: https://patch.msgid.link/20260527174347.2356165-6-jmattson@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-26KVM: selftests: Add nested page fault injection testKevin Cheng
Add a test that exercises nested page fault injection during L2 execution. L2 executes I/O string instructions (OUTSB/INSB) that access memory restricted in L1's nested page tables (NPT/EPT), triggering a nested page fault that L0 must inject to L1. The test supports both AMD SVM (NPF) and Intel VMX (EPT violation) and verifies that: - The exit reason is an NPF/EPT violation - The access type and permission bits are correct - The faulting GPA is correct Three test cases are implemented: - Unmap the final data page (final translation fault, OUTSB read) - Unmap a PT page (page walk fault, OUTSB read) - Write-protect the final data page (protection violation, INSB write) - Write-protect a PT page (protection violation on A/D update, OUTSB read) Signed-off-by: Kevin Cheng <chengkev@google.com> [sean: name it nested_tdp_fault_test, consolidate asserts] Link: https://patch.msgid.link/20260522232701.3671446-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-21KVM: selftests: Add all (known) EFLAGS bit definitionsSean Christopherson
Add #defines for all known EFLAGS bit, e.g. so that tests can use things like EFLAGS.TF to validate single-stepping behavior. Opportunistically use X86_EFLAGS_FIXED instead of an open-coded equivalent when stuffing initial vCPU state. No functional change intended. Link: https://patch.msgid.link/20260515222638.1949982-9-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: selftests: Add a test to verify SEV {en,de}crypt debug ioctlsSean Christopherson
Add a selftest to verify KVM's handling of {de,en}crypt debug ioctls, specifically focusing on edge cases around the chunk (16 bytes) and page (4096) sizes, where KVM had multiple bugs. E.g. KVM would fail to handle small sizes that aren't naturally aligned and sized, would buffer overflow if the destination was unaligned but the source was not, etc. Attempt to strike a balance between an exhaustive test and a reasonable runtime. On a system with both SEV and SEV-ES support, the current runtime is under 45 seconds. Which isn't great, but it's tolerable, and it's not obvious which of the combinations are "better" than the others. Link: https://patch.msgid.link/20260501203537.2120074-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-20KVM: selftests: Replace "paddr" with "gpa" throughoutSean Christopherson
Replace all variations of "paddr" variables in KVM selftests with "gpa", with the exception of the ELF structures, as those fields are not specific to guest virtual addresses, to complete the conversion from vm_paddr_t to gpa_t. No functional change intended. Link: https://patch.msgid.link/20260420212004.3938325-20-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-20KVM: selftests: Replace "u64 nested_paddr" with "gpa_t l2_gpa"Sean Christopherson
In x86's nested TDP APIs, use the appropriate gpa_t typedef and rename variables from nested_paddr to l2_gpa to match KVM x86's nomenclature. No functional change intended. Link: https://patch.msgid.link/20260420212004.3938325-19-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-20KVM: selftests: Replace "u64 gpa" with "gpa_t" throughoutSean Christopherson
Use gpa_t instead of u64 for obvious declarations of GPA variables. No functional change intended. Link: https://patch.msgid.link/20260420212004.3938325-18-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-20KVM: selftests: Replace "vaddr" with "gva" throughoutSean Christopherson
Replace all variations of "vaddr" variables in KVM selftests with "gva", with the exception of the ELF structures, as those fields are not specific to guest virtual addresses, to complete the conversion from vm_vaddr_t to gva_t. Opportunistically use gva_t instead of u64 for relevant variables, and fixup indentation as appropriate. No functional change intended. Link: https://patch.msgid.link/20260420212004.3938325-17-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-20KVM: selftests: Use u8 instead of uint8_tDavid Matlack
Use u8 instead of uint8_t to make the KVM selftests code more concise and more similar to the kernel (since selftests are primarily developed by kernel developers). This commit was generated with the following command: git ls-files tools/testing/selftests/kvm | xargs sed -i 's/uint8_t/u8/g' Then by manually adjusting whitespace to make checkpatch.pl happy. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> Link: https://patch.msgid.link/20260420212004.3938325-11-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-20KVM: selftests: Use u16 instead of uint16_tDavid Matlack
Use u16 instead of uint16_t to make the KVM selftests code more concise and more similar to the kernel (since selftests are primarily developed by kernel developers). This commit was generated with the following command: git ls-files tools/testing/selftests/kvm | xargs sed -i 's/uint16_t/u16/g' Then by manually adjusting whitespace to make checkpatch.pl happy. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> Link: https://patch.msgid.link/20260420212004.3938325-9-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-20KVM: selftests: Use u32 instead of uint32_tDavid Matlack
Use u32 instead of uint32_t to make the KVM selftests code more concise and more similar to the kernel (since selftests are primarily developed by kernel developers). This commit was generated with the following command: git ls-files tools/testing/selftests/kvm | xargs sed -i 's/uint32_t/u32/g' Then by manually adjusting whitespace to make checkpatch.pl happy. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> Link: https://patch.msgid.link/20260420212004.3938325-7-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-20KVM: selftests: Use u64 instead of uint64_tDavid Matlack
Use u64 instead of uint64_t to make the KVM selftests code more concise and more similar to the kernel (since selftests are primarily developed by kernel developers). This commit was generated with the following command: git ls-files tools/testing/selftests/kvm | xargs sed -i 's/uint64_t/u64/g' Then by manually adjusting whitespace to make checkpatch.pl happy. Include <linux/types.h> in include/kvm_util_types.h, iinclude/test_util.h, and include/x86/pmu.h to pick up the tools-defined u64. Arguably, all headers (especially kvm_util_types.h) should have already been including stdint.h to get uint64_t from the libc headers, but the missing dependency only rears its head once KVM uses u64 instead of uint64_t. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> [sean: rename pread_uint64() => pread_u64, expand on types.h include] Link: https://patch.msgid.link/20260420212004.3938325-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
generated by cgit v1.2.3 (git 2.0.4) at 2026-10-29 21:37:54 +0000