On 5/11/26 10:34 PM, David Woodhouse wrote:
> 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
Thank you very much! The explanation is very detailed, including the part about
the local host live update.
Dongli Zhang
