Re: [PATCH v5 00/34] Cleaning up the KVM clock mess

[David Woodhouse]

On Mon, 2026-06-08 at 15:47 +0100, David Woodhouse wrote:
> This is v5 of the series to clean up the KVM clock, rebased onto
> tip/timers/ptp (which now includes Thomas's ktime snapshot series and
> the read_snapshot patches for hyperv, kvmclock, and vmclock).
> 
> The KVM clock has historically suffered from three problems:
> 
>  1. Imprecision: get_kvmclock_ns() computed the clock from the *host*
>     TSC without applying guest TSC scaling, causing systemic drift from
>     the values the guest computes from its own TSC.
> 
>  2. Unnecessary discontinuities: gratuitous KVM_REQ_MASTERCLOCK_UPDATE
>     requests caused the master clock reference point to be re-snapshotted,
>     yanking the guest's clock due to arithmetic precision differences.
> 
>  3. No precise migration API: the existing KVM_[GS]ET_CLOCK only allows
>     setting the clock at a given UTC reference time, which is necessarily
>     imprecise. There was no way to preserve the exact arithmetic
>     relationship between guest TSC and KVM clock across live migration.
> 
> This series addresses all three, and adds new APIs for precise clock 
> migration and TSC frequency reporting. As an added bonus, it now rips
> out the whole pvclock_gtod_data hack which was shadowing the kernel's
> timekeeping, and uses ktime snapshots as $DEITY (well, Thomas) intended.

Updated series with Sashiko's fixes pushed out to
https://git.infradead.org/?p=users/dwmw2/linux.git;a=shortlog;h=refs/heads/kvmclock6

I'll give it a while for meat-based reviewers to opine before sending
another round. (Is there a way to get Sashiko to take another look
without sending it all to the list again?)

Attachment: smime.p7s
Description: S/MIME cryptographic signature