Re: pvclock time drifting backward

[David Woodhouse <dwmw2@infradead.org>]

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

On Wed, 2025-03-26 at 08:54 -0700, Ming Lin wrote:
> I applied the patch series on top of 6.9 cleanly and tested it with my
> debug tool patch.
> But it seems the time drift still increased monotonically.
> 
> Would you help take a look if the tool patch makes sense?
> https://github.com/minggr/linux/commit/5284a211b6bdc9f9041b669539558a6a858e88d0
> 
> The tool patch adds a KVM debugfs entry to trigger time calculations
> and print the results.
> See my first email for more detail.

Your first message seemed to say that the problem occurred with live
migration. This message says "the time drift still increased
monotonically". 

Trying to make sure I fully understand... the time drift between the
host's CLOCK_MONOTONIC_RAW and the guest's kvmclock increases
monotonically *but* the guest only observes the change when its
master_kernel_ns/master_cycle_now are updated (e.g. on live migration)
and its kvmclock is reset back to the host's CLOCK_MONOTONIC_RAW?

Is this live migration from one VMM to another on the same host, so we
don't have to worry about the accuracy of the TSC itself? The guest TSC
remains consistent? And presumably your host does *have* a stable TSC,
and the guest's test case really ought to be checking the
PVCLOCK_TSC_STABLE_BIT to make sure of that?

If all the above assumptions/interpretations of mine are true, I still
think it's expected that your clock will jump on live migration
*unless* you also taught your VMM to use the new KVM_[GS]ET_CLOCK_GUEST
ioctls which were added in my patch series, specifically to preserve
the mathematical relationship between guest TSC and kvmclock across a
migration.



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