[PATCH v11 21/23] KVM: selftests: Test that the first user TSC write is honoured exactly

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

From: David Woodhouse <dwmw@xxxxxxxxxxxx>

The 1-second "slop" heuristic in kvm_synchronize_tsc() is only
supposed to apply between successive userspace TSC writes, i.e. once
kvm->arch.user_set_tsc has been set by a previous write. The kernel's
own internal TSC synchronization on vCPU creation (and frequency
changes) must not arm it, otherwise the first genuine userspace write
falling within 1 second of virtual cycle time of the kernel's default
generation is "corrected" back to that generation instead of being
honoured — breaking the restore of a guest with less than one second
of runtime.

Add a test which creates a vCPU and immediately performs a first
host-initiated write of a TSC value corresponding to ~500ms of guest
runtime, then verifies the value reads back exactly (modulo elapsed
time) rather than being snapped back to the kernel's default
generation near zero.

Signed-off-by: David Woodhouse <dwmw@xxxxxxxxxxxx>
---
 tools/testing/selftests/kvm/Makefile.kvm      |  1 +
 .../selftests/kvm/x86/tsc_user_set_test.c     | 86 +++++++++++++++++++
 2 files changed, 87 insertions(+)
 create mode 100644 tools/testing/selftests/kvm/x86/tsc_user_set_test.c

diff --git a/tools/testing/selftests/kvm/Makefile.kvm 
b/tools/testing/selftests/kvm/Makefile.kvm
index 1edc78845fd3..fd063806a7fb 100644
--- a/tools/testing/selftests/kvm/Makefile.kvm
+++ b/tools/testing/selftests/kvm/Makefile.kvm
@@ -151,6 +151,7 @@ TEST_GEN_PROGS_x86 += x86/xcr0_cpuid_test
 TEST_GEN_PROGS_x86 += x86/xss_msr_test
 TEST_GEN_PROGS_x86 += x86/debug_regs
 TEST_GEN_PROGS_x86 += x86/tsc_msrs_test
+TEST_GEN_PROGS_x86 += x86/tsc_user_set_test
 TEST_GEN_PROGS_x86 += x86/vmx_pmu_caps_test
 TEST_GEN_PROGS_x86 += x86/xen_cpuid_timing_test
 TEST_GEN_PROGS_x86 += x86/xen_migration_test
diff --git a/tools/testing/selftests/kvm/x86/tsc_user_set_test.c 
b/tools/testing/selftests/kvm/x86/tsc_user_set_test.c
new file mode 100644
index 000000000000..6ab76e817f9f
--- /dev/null
+++ b/tools/testing/selftests/kvm/x86/tsc_user_set_test.c
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Test that the first userspace write to MSR_IA32_TSC takes effect
+ * precisely, and is not subjected to the 1-second "slop" heuristic
+ * which is only supposed to apply between successive *userspace*
+ * writes (kvm->arch.user_set_tsc).
+ *
+ * The kernel synchronizes the TSC internally when a vCPU is created
+ * (and when its frequency is set). If any of those kernel-internal
+ * paths incorrectly sets user_set_tsc, then the first genuine write
+ * from userspace which happens to fall within 1 second of virtual
+ * cycle time of the kernel's default generation is "corrected" to
+ * match that generation instead of being honoured exactly. That
+ * breaks the restore of a guest which has genuinely been running
+ * for less than one second.
+ *
+ * Simulate exactly that: create a vCPU (kernel establishes a default
+ * TSC generation starting near zero), then perform the first
+ * host-initiated write with a value corresponding to ~500ms of guest
+ * runtime. If the slop heuristic fires, the written value is snapped
+ * back to the kernel's generation (near zero) and the TSC reads back
+ * hundreds of milliseconds low.
+ */
+#include "kvm_util.h"
+#include "processor.h"
+
+int main(void)
+{
+       struct kvm_vcpu *vcpu;
+       struct kvm_vm *vm;
+       u64 freq_khz, t_write, t_read, slack_cycles, mono_ns;
+       struct timespec ts;
+       int r;
+
+       /*
+        * Start the measured window before vCPU creation: a snapped-back
+        * value tracks time since the kernel's default generation (i.e.
+        * since creation), so the window the slack is derived from must
+        * include everything from creation onwards.
+        */
+       clock_gettime(CLOCK_MONOTONIC_RAW, &ts);
+       mono_ns = ts.tv_sec * 1000000000ULL + ts.tv_nsec;
+
+       vm = vm_create_with_one_vcpu(&vcpu, NULL);
+
+       r = __vcpu_ioctl(vcpu, KVM_GET_TSC_KHZ, NULL);
+       TEST_ASSERT(r > 0, "KVM_GET_TSC_KHZ failed");
+       freq_khz = r;
+
+       /*
+        * The first user write: a guest TSC corresponding to 500ms of
+        * runtime. This is within 1s (of virtual cycle time) of the
+        * kernel's default generation, so it is exactly the case that
+        * the slop heuristic would destroy if it were (incorrectly)
+        * armed by the kernel's own internal TSC synchronization.
+        */
+       t_write = freq_khz * 500ULL;            /* khz * ms = cycles */
+
+       vcpu_set_msr(vcpu, MSR_IA32_TSC, t_write);
+
+       t_read = vcpu_get_msr(vcpu, MSR_IA32_TSC);
+
+       clock_gettime(CLOCK_MONOTONIC_RAW, &ts);
+       mono_ns = (ts.tv_sec * 1000000000ULL + ts.tv_nsec) - mono_ns;
+
+       /*
+        * The TSC advances between the write and the read; bound the
+        * difference by the measured elapsed time around the two ioctls
+        * plus 10ms of slop, so a descheduled test cannot flake. If the
+        * write was snapped to the kernel's default generation, the
+        * value read back is ~500ms low (i.e. below t_write), which is
+        * unambiguous.
+        */
+       slack_cycles = freq_khz * (mono_ns / 1000000ULL + 10);
+
+       TEST_ASSERT(t_read >= t_write,
+                   "TSC went backwards from explicit write: wrote %lu, read 
%lu"
+                   " (first userspace write was subjected to 1-second slop?)",
+                   t_write, t_read);
+       TEST_ASSERT(t_read - t_write < slack_cycles,
+                   "TSC read back too far from written value: wrote %lu, read 
%lu",
+                   t_write, t_read);
+
+       kvm_vm_free(vm);
+       return 0;
+}
-- 
2.43.0