Re: [RFC PATCH v2 0/8] timekeeping: Fix draft tracking precision and add feed-forward discipline via vmclock

[Miroslav Lichvar]

On Sun, May 17, 2026 at 10:25:37PM +0100, David Woodhouse wrote:
> The vmclock device (https://uapi-group.org/specifications/specs/vmclock/)
> provides a shared memory page containing a linear time function:
> time = base + (counter - counter_value) × period. The guest can read
> this at any time to determine the hypervisor's view of the current time,
> without a VM exit.

That sounds nice.

> The existing ptp_vmclock driver already exposes this as a PTP clock for
> userspace consumers (phc2sys, chrony). This series adds kernel-internal
> consumption: the tick mechanism can clamp directly to the vmclock
> reference, eliminating the need for NTP to discipline the guest clock.

I'm not very familiar with the VM timekeeping and other code. If I
understand this idea correctly, by loading the ptp_vmclock module the
guest kernel is giving the host control of its clock. Changes in the
host's REALTIME/MONOTONIC clock frequency are mirrored to the guest's
clock. Differences larger than 100 milliseconds are corrected by step,
whether the guest applications like it or not. Smaller steps and
errors accumulated due to a delay in the frequency update (is there a
limit to this delay?) are corrected by the kernel NTP PLL (with the
default time constant?). When the guest is migrated to a different
host, the frequency offset between the two hosts is injected to the
NTP frequency (assuming REALTIME clocks of the hosts have zero
frequency error at that moment?).

Have you considered a different approach that would address the
problem with frequency step by adjusting the guest's clocksource
frequency to match the original host? That would correct all system
clocks, i.e. not only REALTIME/MONOTONIC, but also MONOTONIC_RAW and
AUX clocks.

The guest would still be in control of its clock and follow its own
preferences to stepping, maximum frequency errors, etc. It could still
compare the stability and accuracy of the host's clock and use it for
synchronization only when it's actually better than other available
time sources (some VPS providers are known to have poorly synchronized
host clocks). An AUX clock could be used to more accurately compare
frequencies of the two hosts, ignoring phase corrections.

There is a work in progress for chrony to support MONOTONIC_RAW as the
main clock. It would be nice if that could be corrected in migrations.
That seems to be a common cause of disruptions of public NTP servers.
Polling for notifications about clock changes caused by migrations and
system suspend+resume would be useful in any case.

-- 
Miroslav Lichvar