Re: [PATCH 3/5] KVM: x86: account KVM_SET_CLOCK downtime in steal time

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1789 bytes --]

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

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]