blaster4385/linux-IllusionX/tools/testing/selftests/kvm/include/x86_64, branch v6.13

KVM: selftests: Configure XCR0 to max supported value by default

2024-11-01T16:26:31Z

To play nice with compilers generating AVX instructions, set CR4.OSXSAVE and configure XCR0 by default when creating selftests vCPUs. Some distros have switched gcc to '-march=x86-64-v3' by default, and while it's hard to find a CPU which doesn't support AVX today, many KVM selftests fail with ==== Test Assertion Failure ==== lib/x86_64/processor.c:570: Unhandled exception in guest pid=72747 tid=72747 errno=4 - Interrupted system call Unhandled exception '0x6' at guest RIP '0x4104f7' due to selftests not enabling AVX by default for the guest. The failure is easy to reproduce elsewhere with: $ make clean && CFLAGS='-march=x86-64-v3' make -j && ./x86_64/kvm_pv_test E.g. gcc-13 with -march=x86-64-v3 compiles this chunk from selftests' kvm_fixup_exception(): regs->rip = regs->r11; regs->r9 = regs->vector; regs->r10 = regs->error_code; into this monstronsity (which is clever, but oof): 405313: c4 e1 f9 6e c8 vmovq %rax,%xmm1 405318: 48 89 68 08 mov %rbp,0x8(%rax) 40531c: 48 89 e8 mov %rbp,%rax 40531f: c4 c3 f1 22 c4 01 vpinsrq $0x1,%r12,%xmm1,%xmm0 405325: 49 89 6d 38 mov %rbp,0x38(%r13) 405329: c5 fa 7f 45 00 vmovdqu %xmm0,0x0(%rbp) Alternatively, KVM selftests could explicitly restrict the compiler to -march=x86-64-v2, but odds are very good that punting on AVX enabling will simply result in tests that "need" AVX doing their own thing, e.g. there are already three or so additional cleanups that can be done on top. Reported-by: Vitaly Kuznetsov Closes: https://lore.kernel.org/all/20240920154422.2890096-1-vkuznets@redhat.com Reviewed-and-tested-by: Vitaly Kuznetsov Link: https://lore.kernel.org/r/20241003234337.273364-6-seanjc@google.com Signed-off-by: Sean Christopherson

Merge tag 'kvm-x86-selftests-6.12' of https://github.com/kvm-x86/linux into HEAD

2024-09-17T15:39:21Z

KVM selftests changes for 6.12: - Fix a goof that caused some Hyper-V tests to be skipped when run on bare metal, i.e. NOT in a VM. - Add a regression test for KVM's handling of SHUTDOWN for an SEV-ES guest. - Explicitly include one-off assets in .gitignore. Past Sean was completely wrong about not being able to detect missing .gitignore entries. - Verify userspace single-stepping works when KVM happens to handle a VM-Exit in its fastpath. - Misc cleanups

KVM: selftests: Add x86 helpers to play nice with x2APIC MSR #GPs

2024-08-29T23:25:06Z

Add helpers to allow and expect #GP on x2APIC MSRs, and opportunistically have the existing helper spit out a more useful error message if an unexpected exception occurs. Link: https://lore.kernel.org/r/20240719235107.3023592-7-seanjc@google.com Signed-off-by: Sean Christopherson

KVM: selftests: Re-enable hyperv_evmcs/hyperv_svm_test on bare metal

2024-08-22T19:14:42Z

KVM_CAP_HYPERV_DIRECT_TLBFLUSH is only reported when KVM runs on top of Hyper-V and hyperv_evmcs/hyperv_svm_test don't need that, these tests check that the feature is properly emulated for Hyper-V on KVM guests. There's no corresponding CAP for that, the feature is reported in KVM_GET_SUPPORTED_HV_CPUID. Hyper-V specific CPUIDs are not reported by KVM_GET_SUPPORTED_CPUID, implement dedicated kvm_hv_cpu_has() helper to do the job. Fixes: 6dac1195181c ("KVM: selftests: Make Hyper-V tests explicitly require KVM Hyper-V support") Signed-off-by: Vitaly Kuznetsov Link: https://lore.kernel.org/r/20240816130139.286246-3-vkuznets@redhat.com Signed-off-by: Sean Christopherson

KVM: selftests: Move Hyper-V specific functions out of processor.c

2024-08-22T19:14:42Z

Since there is 'hyperv.c' for Hyper-V specific functions already, move Hyper-V specific functions out of processor.c there. No functional change intended. Signed-off-by: Vitaly Kuznetsov Link: https://lore.kernel.org/r/20240816130139.286246-2-vkuznets@redhat.com Signed-off-by: Sean Christopherson

Merge tag 'kvm-x86-misc-6.11' of https://github.com/kvm-x86/linux into HEAD

2024-07-16T13:53:05Z

KVM x86 misc changes for 6.11 - Add a global struct to consolidate tracking of host values, e.g. EFER, and move "shadow_phys_bits" into the structure as "maxphyaddr". - Add KVM_CAP_X86_APIC_BUS_CYCLES_NS to allow configuring the effective APIC bus frequency, because TDX. - Print the name of the APICv/AVIC inhibits in the relevant tracepoint. - Clean up KVM's handling of vendor specific emulation to consistently act on "compatible with Intel/AMD", versus checking for a specific vendor. - Misc cleanups

KVM: selftests: Add test for configure of x86 APIC bus frequency

2024-06-28T22:21:43Z

Test if KVM emulates the APIC bus clock at the expected frequency when userspace configures the frequency via KVM_CAP_X86_APIC_BUS_CYCLES_NS. Set APIC timer's initial count to the maximum value and busy wait for 100 msec (largely arbitrary) using the TSC. Read the APIC timer's "current count" to calculate the actual APIC bus clock frequency based on TSC frequency. Suggested-by: Sean Christopherson Signed-off-by: Isaku Yamahata Co-developed-by: Reinette Chatre Signed-off-by: Reinette Chatre Link: https://lore.kernel.org/r/2fccf35715b5ba8aec5e5708d86ad7015b8d74e6.1718214999.git.reinette.chatre@intel.com Signed-off-by: Sean Christopherson

KVM: selftests: Add guest udelay() utility for x86

2024-06-28T18:40:38Z

Add udelay() for x86 tests to allow busy waiting in the guest for a specific duration, and to match ARM and RISC-V's udelay() in the hopes of eventually making udelay() available on all architectures. Get the guest's TSC frequency using KVM_GET_TSC_KHZ and expose it to all VMs via a new global, guest_tsc_khz. Assert that KVM_GET_TSC_KHZ returns a valid frequency, instead of simply skipping tests, which would require detecting which tests actually need/want udelay(). KVM hasn't returned an error for KVM_GET_TSC_KHZ since commit cc578287e322 ("KVM: Infrastructure for software and hardware based TSC rate scaling"), which predates KVM selftests by 6+ years (KVM_GET_TSC_KHZ itself predates KVM selftest by 7+ years). Note, if the GUEST_ASSERT() in udelay() somehow fires and the test doesn't check for guest asserts, then the test will fail with a very cryptic message. But fixing that, e.g. by automatically handling guest asserts, is a much larger task, and practically speaking the odds of a test afoul of this wart are infinitesimally small. Signed-off-by: Reinette Chatre Link: https://lore.kernel.org/r/5aa86285d1c1d7fe1960e3fe490f4b22273977e6.1718214999.git.reinette.chatre@intel.com Co-developed-by: Sean Christopherson Signed-off-by: Sean Christopherson

KVM: selftests: x86: Prioritize getting max_gfn from GuestPhysBits

2024-06-05T13:16:10Z

Use the max mappable GPA via GuestPhysBits advertised by KVM to calculate max_gfn. Currently some selftests (e.g. access_tracking_perf_test, dirty_log_test...) add RAM regions close to max_gfn, so guest may access GPA beyond its mappable range and cause infinite loop. Adjust max_gfn in vm_compute_max_gfn() since x86 selftests already overrides vm_compute_max_gfn() specifically to deal with goofy edge cases. Reported-by: Yi Lai Signed-off-by: Tao Su Tested-by: Yi Lai Reviewed-by: Xiaoyao Li Link: https://lore.kernel.org/r/20240513014003.104593-1-tao1.su@linux.intel.com [sean: tweak name, add comment and sanity check] Signed-off-by: Sean Christopherson

KVM: selftests: Init IDT and exception handlers for all VMs/vCPUs on x86

2024-04-29T19:55:15Z

Initialize the IDT and exception handlers for all non-barebones VMs and vCPUs on x86. Forcing tests to manually configure the IDT just to save 8KiB of memory is a terrible tradeoff, and also leads to weird tests (multiple tests have deliberately relied on shutdown to indicate success), and hard-to-debug failures, e.g. instead of a precise unexpected exception failure, tests see only shutdown. Reviewed-by: Ackerley Tng Link: https://lore.kernel.org/r/20240314232637.2538648-11-seanjc@google.com Signed-off-by: Sean Christopherson