Re: [Devel] [PATCH hci-8.1 v2] KVM: nVMX: Keep the emulated VMX-preemption timer on L1's TSC

["Denis V. Lunev" <den@openvz.org>]

On 06.11.2026 17:09, Eva Kurchatova wrote:
> KVM emulates L2's VMX-preemption timer with an hrtimer, but the hrtimer
> runs on CLOCK_MONOTONIC, which NTP slews against the TSC. The VM-exit
> then comes late or early in L1's TSC, and vmx_preemption_timer_test
> fails.

NAK. NTP did not fail the test. The node's TSC did. The journal of
sqvm2-4019 for the boot that produced VSTOR-152991:

  13:58:47 clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large:
  13:58:47 clocksource:   Clocksource 'tsc' skewed -42289835 ns (-42 ms) over watchdog 'kvm-clock' interval of 495964472 ns (495 ms)
  13:58:47 tsc: Marking TSC unstable due to clocksource watchdog
  15:38:36 kvm: SMP vm created on host with unstable TSC; guest TSC will not be reliable
  15:39:14 vmx_preemption_timer_test: not ok

sqvm2-4019 is itself a VM, and its hypervisor moved the TSC by 42 ms
within half a second. KVM warned that the guest TSC would not be
reliable 38 seconds before the test ran. With an unstable host TSC,
KVM rewrites L1's TSC offset on every vcpu_load and catches it up
later, so no emulation keyed on L1's TSC can be exact there, including
this patch's.

The test does not need an exact timer either. L2 computes its deadline
after the VMCALL round trip, so the exit may land anywhere in a window
of about 0.8 ms at 2.8 GHz. That is about 700 ppm of disagreement
between CLOCK_MONOTONIC and the TSC over the whole timer, and far more
over the part re-armed after the save/restore. NTP slews at most
500 ppm, so it cannot fail this test on a sane node.

On the other side of the scale, the patch changes timer emulation on
production hosts:

- the hrtimer now fires up to 8 times per period instead of once, and
  each extra firing is an exit from the running L2;
- the callback now follows every change of l1_tsc_offset while L2
  runs. An L2 write to IA32_TSC that L1 does not intercept, S3 with a
  TSC reset, or the unstable-TSC offset rewrite each make it re-arm
  for up to U32_MAX ticks (about 48 s), where the old countdown fired
  on time.

Upstream knows the emulation is imprecise and has not taken a fix
either (https://bugzilla.kernel.org/show_bug.cgi?id=216177, and
https://bugzilla.kernel.org/show_bug.cgi?id=218025 with the same
"L2 PT expiry TSC > L2 TSC deadline" failure). I do not want to carry a
downstream-only rework of it to cover a test run on a broken clock.

What I would like instead:

1. QA: skip vmx_preemption_timer_test on nodes with an unstable TSC.
   The watchdog clears CLOCK_SOURCE_VALID_FOR_HRES on the TSC, which
   drops it from available_clocksource, so the check survives a
   wrapped dmesg:

     grep -qw tsc /sys/devices/system/clocksource/clocksource0/available_clocksource

   sys_clocksource_is_based_on_tsc() from the selftest library is not
   the right guard: it rejects kvm-clock and would skip the test on
   every sqvm.

2. There is one real bug you found along the way, and I would take a
   patch for it on its own. vmx_calc_preemption_timer_value() returns
   preemption_timer_deadline - l1_scaled_tsc unclamped. When the
   deadline has already passed, after RSM from a long SMM handler or
   KVM_SET_NESTED_STATE after a long downtime, it underflows and
   vmx_start_preemption_timer() arms the hrtimer for up to about two
   hours instead of exiting at once. Clamping it to 0 is a few lines
   that do not touch the hrtimer callback. Mainline has the same code,
   so please send it upstream as well.

So there is no v3 of this patch.

Please send the clamp as a new patch to mainstream first.

Den
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel