On Mon, 2025-09-22 at 09:37 -0700, Dongli Zhang wrote: > Hi, > > Would you mind helping confirm if kvm-clock/guest_tsc should stop counting > elapsed time during downtime blackout? > > 1. guest_clock=T1, realtime=R1. > 2. (qemu) stop > 3. Wait for several seconds. > 4. (qemu) cont > 5. guest_clock=T2, realtime=R2. > > Should (T1 == T2), or (R2 - R1 == T2 - T1)?
Neither. Realtime is something completely different and runs at a different rate to the monotonic clock. In fact its rate compared to the monotonic clock (and the TSC) is *variable* as NTP guides it. In your example of stopping and continuing on the *same* host, the guest TSC *offset* from the host's TSC should remain the same. And the *precise* mathematical relationship that KVM advertises to the guest as "how to turn a TSC value into nanoseconds since boot" should also remain precisely the same. KVM already lets you restore the TSC correctly. To restore KVM clock correctly, you want something like KVM_SET_CLOCK_GUEST from https://lore.kernel.org/all/[email protected]/ For cross machine migration, you *do* need to use a realtime clock reference as that's the best you have (make sure you use TAI not UTC and don't get affected by leap seconds or smearing). Use that to restore the *TSC* as well as you can to make it appear to have kept running consistently. And then KVM_SET_CLOCK_GUEST just as you would on the same host. And use vmclock to advertise the wallclock time to the guest as precisely as possible, even the cycle after a live migration.
smime.p7s
Description: S/MIME cryptographic signature
