kernel/linux.git/tools/testing/selftests/kvm, branch v6.6.131

KVM: selftests: Add -U_FORTIFY_SOURCE to avoid some unpredictable test failures

2026-02-11T12:39:09+00:00

[ Upstream commit e396a74222654486d6ab45dca5d0c54c408b8b91 ] Some distributions (such as Ubuntu) configure GCC so that _FORTIFY_SOURCE is automatically enabled at -O1 or above. This results in some fortified version of definitions of standard library functions are included. While linker resolves the symbols, the fortified versions might override the definitions in lib/string_override.c and reference to those PLT entries in GLIBC. This is not a problem for the code in host, but it is a disaster for the guest code. E.g., if build and run x86/nested_emulation_test on Ubuntu 24.04 will encounter a L1 #PF due to memset() reference to __memset_chk@plt. The option -fno-builtin-memset is not helpful here, because those fortified versions are not built-in but some definitions which are included by header, they are for different intentions. In order to eliminate the unpredictable behaviors may vary depending on the linker and platform, add the "-U_FORTIFY_SOURCE" into CFLAGS to prevent from introducing the fortified definitions. Signed-off-by: Zhiquan Li Link: https://patch.msgid.link/20260122053551.548229-1-zhiquan_li@163.com Fixes: 6b6f71484bf4 ("KVM: selftests: Implement memcmp(), memcpy(), and memset() for guest use") Cc: stable@vger.kernel.org [sean: tag for stable] Signed-off-by: Sean Christopherson [ Makefile.kvm -> Makefile ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

KVM: selftests: Add test for uaccesses to non-existent vgic-v2 CPUIF

2024-06-12T09:11:27+00:00

[ Upstream commit 160933e330f4c5a13931d725a4d952a4b9aefa71 ] Assert that accesses to a non-existent vgic-v2 CPU interface consistently fail across the various KVM device attr ioctls. This also serves as a regression test for a bug wherein KVM hits a NULL dereference when the CPUID specified in the ioctl is invalid. Note that there is no need to print the observed errno, as TEST_ASSERT() will take care of it. Reviewed-by: Marc Zyngier Link: https://lore.kernel.org/r/20240424173959.3776798-3-oliver.upton@linux.dev Signed-off-by: Oliver Upton Signed-off-by: Sasha Levin

KVM: selftests: Fix a semaphore imbalance in the dirty ring logging test

2024-02-23T08:24:49+00:00

[ Upstream commit ba58f873cdeec30b6da48e28dd5782c5a3e1371b ] When finishing the final iteration of dirty_log_test testcase, set host_quit _before_ the final "continue" so that the vCPU worker doesn't run an extra iteration, and delete the hack-a-fix of an extra "continue" from the dirty ring testcase. This fixes a bug where the extra post to sem_vcpu_cont may not be consumed, which results in failures in subsequent runs of the testcases. The bug likely was missed during development as x86 supports only a single "guest mode", i.e. there aren't any subsequent testcases after the dirty ring test, because for_each_guest_mode() only runs a single iteration. For the regular dirty log testcases, letting the vCPU run one extra iteration is a non-issue as the vCPU worker waits on sem_vcpu_cont if and only if the worker is explicitly told to stop (vcpu_sync_stop_requested). But for the dirty ring test, which needs to periodically stop the vCPU to reap the dirty ring, letting the vCPU resume the guest _after_ the last iteration means the vCPU will get stuck without an extra "continue". However, blindly firing off an post to sem_vcpu_cont isn't guaranteed to be consumed, e.g. if the vCPU worker sees host_quit==true before resuming the guest. This results in a dangling sem_vcpu_cont, which leads to subsequent iterations getting out of sync, as the vCPU worker will continue on before the main task is ready for it to resume the guest, leading to a variety of asserts, e.g. ==== Test Assertion Failure ==== dirty_log_test.c:384: dirty_ring_vcpu_ring_full pid=14854 tid=14854 errno=22 - Invalid argument 1 0x00000000004033eb: dirty_ring_collect_dirty_pages at dirty_log_test.c:384 2 0x0000000000402d27: log_mode_collect_dirty_pages at dirty_log_test.c:505 3 (inlined by) run_test at dirty_log_test.c:802 4 0x0000000000403dc7: for_each_guest_mode at guest_modes.c:100 5 0x0000000000401dff: main at dirty_log_test.c:941 (discriminator 3) 6 0x0000ffff9be173c7: ?? ??:0 7 0x0000ffff9be1749f: ?? ??:0 8 0x000000000040206f: _start at ??:? Didn't continue vcpu even without ring full Alternatively, the test could simply reset the semaphores before each testcase, but papering over hacks with more hacks usually ends in tears. Reported-by: Shaoqin Huang Fixes: 84292e565951 ("KVM: selftests: Add dirty ring buffer test") Reviewed-by: Peter Xu Reviewed-by: Shaoqin Huang Link: https://lore.kernel.org/r/20240202231831.354848-1-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin

KVM: selftests: Avoid infinite loop in hyperv_features when invtsc is missing

2024-02-23T08:24:49+00:00

[ Upstream commit 8ad4855273488c9bd5320b3fee80f66f0023f326 ] When X86_FEATURE_INVTSC is missing, guest_test_msrs_access() was supposed to skip testing dependent Hyper-V invariant TSC feature. Unfortunately, 'continue' does not lead to that as stage is not incremented. Moreover, 'vm' allocated with vm_create_with_one_vcpu() is not freed and the test runs out of available file descriptors very quickly. Fixes: bd827bd77537 ("KVM: selftests: Test Hyper-V invariant TSC control") Signed-off-by: Vitaly Kuznetsov Link: https://lore.kernel.org/r/20240129085847.2674082-1-vkuznets@redhat.com Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin

KVM: selftests: Delete superfluous, unused "stage" variable in AMX test

2024-02-23T08:24:48+00:00

[ Upstream commit 46fee9e38995af9ae16a8cc7d05031486d44cf35 ] Delete the AMX's tests "stage" counter, as the counter is no longer used, which makes clang unhappy: x86_64/amx_test.c:224:6: error: variable 'stage' set but not used int stage, ret; ^ 1 error generated. Note, "stage" was never really used, it just happened to be dumped out by a (failed) assertion on run->exit_reason, i.e. the AMX test has no concept of stages, the code was likely copy+pasted from a different test. Fixes: c96f57b08012 ("KVM: selftests: Make vCPU exit reason test assertion common") Reviewed-by: Jim Mattson Link: https://lore.kernel.org/r/20240109220302.399296-1-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin

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

2023-10-15T12:25:18+00:00

KVM selftests fixes for 6.6: - Play nice with %llx when formatting guest printf and assert statements. - Clean up stale test metadata. - Zero-initialize structures in memslot perf test to workaround a suspected "may be used uninitialized" false positives from GCC.

KVM: selftests: Force load all supported XSAVE state in state test

2023-10-12T15:08:59+00:00

Extend x86's state to forcefully load *all* host-supported xfeatures by modifying xstate_bv in the saved state. Stuffing xstate_bv ensures that the selftest is verifying KVM's full ABI regardless of whether or not the guest code is successful in getting various xfeatures out of their INIT state, e.g. see the disaster that is/was MPX. Signed-off-by: Sean Christopherson Message-Id: <20230928001956.924301-6-seanjc@google.com> Signed-off-by: Paolo Bonzini

KVM: selftests: Load XSAVE state into untouched vCPU during state test

2023-10-12T15:08:59+00:00

Expand x86's state test to load XSAVE state into a "dummy" vCPU prior to KVM_SET_CPUID2, and again with an empty guest CPUID model. Except for off-by-default features, i.e. AMX, KVM's ABI for KVM_SET_XSAVE is that userspace is allowed to load xfeatures so long as they are supported by the host. This is a regression test for a combination of KVM bugs where the state saved by KVM_GET_XSAVE{2} could not be loaded via KVM_SET_XSAVE if the saved xstate_bv would load guest-unsupported xfeatures. Signed-off-by: Sean Christopherson Message-Id: <20230928001956.924301-5-seanjc@google.com> Signed-off-by: Paolo Bonzini

KVM: selftests: Touch relevant XSAVE state in guest for state test

2023-10-12T15:08:58+00:00

Modify support XSAVE state in the "state test's" guest code so that saving and loading state via KVM_{G,S}ET_XSAVE actually does something useful, i.e. so that xstate_bv in XSAVE state isn't empty. Punt on BNDCSR for now, it's easier to just stuff that xfeature from the host side. Signed-off-by: Sean Christopherson Message-Id: <20230928001956.924301-4-seanjc@google.com> Signed-off-by: Paolo Bonzini

KVM: selftests: Zero-initialize entire test_result in memslot perf test

2023-10-06T02:23:47+00:00

Zero-initialize the entire test_result structure used by memslot_perf_test instead of zeroing only the fields used to guard the pr_info() calls. gcc 13.2.0 is a bit overzealous and incorrectly thinks that rbestslottime's slot_runtime may be used uninitialized. In file included from memslot_perf_test.c:25: memslot_perf_test.c: In function ‘main’: include/test_util.h:31:22: error: ‘rbestslottime.slot_runtime.tv_nsec’ may be used uninitialized [-Werror=maybe-uninitialized] 31 | #define pr_info(...) printf(__VA_ARGS__) | ^~~~~~~~~~~~~~~~~~~ memslot_perf_test.c:1127:17: note: in expansion of macro ‘pr_info’ 1127 | pr_info("Best slot setup time for the whole test area was %ld.%.9lds\n", | ^~~~~~~ memslot_perf_test.c:1092:28: note: ‘rbestslottime.slot_runtime.tv_nsec’ was declared here 1092 | struct test_result rbestslottime; | ^~~~~~~~~~~~~ include/test_util.h:31:22: error: ‘rbestslottime.slot_runtime.tv_sec’ may be used uninitialized [-Werror=maybe-uninitialized] 31 | #define pr_info(...) printf(__VA_ARGS__) | ^~~~~~~~~~~~~~~~~~~ memslot_perf_test.c:1127:17: note: in expansion of macro ‘pr_info’ 1127 | pr_info("Best slot setup time for the whole test area was %ld.%.9lds\n", | ^~~~~~~ memslot_perf_test.c:1092:28: note: ‘rbestslottime.slot_runtime.tv_sec’ was declared here 1092 | struct test_result rbestslottime; | ^~~~~~~~~~~~~ That can't actually happen, at least not without the "result" structure in test_loop() also being used uninitialized, which gcc doesn't complain about, as writes to rbestslottime are all-or-nothing, i.e. slottimens can't be non-zero without slot_runtime being written. if (!data->mem_size && (!rbestslottime->slottimens || result.slottimens < rbestslottime->slottimens)) *rbestslottime = result; Zero-initialize the structures to make gcc happy even though this is likely a compiler bug. The cost to do so is negligible, both in terms of code and runtime overhead. The only downside is that the compiler won't warn about legitimate usage of "uninitialized" data, e.g. the test could end up consuming zeros instead of useful data. However, given that the test is quite mature and unlikely to see substantial changes, the odds of introducing such bugs are relatively low, whereas being able to compile KVM selftests with -Werror detects issues on a regular basis. Reviewed-by: Maciej S. Szmigiero Reviewed-by: Philippe Mathieu-Daudé Link: https://lore.kernel.org/r/20231005002954.2887098-1-seanjc@google.com Signed-off-by: Sean Christopherson