On Mon, 2026-05-11 at 14:46 -0700, Dongli Zhang wrote: > > Thank you very much! > > Based on my understanding, you have two main points: > > 1. KVM_CLOCK_REALTIME is not preferred for live migration or live update. > Essentially, the only acceptable use of KVM_CLOCK_REALTIME is to adjust > guest_TSC. After that, everything should rely on kvm-clock (especially after > KVM_SET_CLOCK_GUEST). > > 2. Regardless of whether TAI or KVM_CLOCK_REALTIME is used to adjust > guest_TSC, > the calculation of the steal-time delta should always and exclusively be based > on kvm-clock values before and after the adjustment. > > Would you mind confirming whether my understanding of your points is correct?
Yeah, I think so. Let me rephrase it as: 1. Any comparison with "real time" should be used *only* for migrating the guest TSC to another physical host on live migration. And not on live update (where the offset from the host TSC remains constant). The time nerds will go on about UTC/TAI and leap seconds, but you can mostly ignore them. 2. The KVM clock should be set in terms of the guest TSC, using the KVM_[GS]ET_CLOCK_GUEST ioctl. (Guests without ->use_master_clock will sadly have to use real time for restoring the KVM clock too.) 3. Absolutely everything else should be set in terms of the KVM clock (nanoseconds) or guest TSC (cycles), never with any relation to 'real time'. Take a look at the selftest I added for Xen steal time, prompted by this. I posted it as [PATCH 33/30] and it's in my kvmclock5 branch, collected with a couple of 32-bit build fixes I'll roll into the next series along with any other review feedback. https://git.infradead.org/?p=users/dwmw2/linux.git;a=shortlog;h=refs/heads/kvmclock5
smime.p7s
Description: S/MIME cryptographic signature
