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

[David Woodhouse]

On Thu, 2026-05-21 at 20:30 +0200, Thomas Gleixner wrote:
> 
> As I said in the other thread, that's just creating yet another private
> mechanism instead of collecting the counter value together with e.g.
> CLOCK_REALTIME 

On the plus side, at least he wasn't providing a counter value at *all*
for the system timestamps, which is better than using a bogus one :)

Can we have a signed-off-by for your ktime_get_snapshot_id() please?

> or utilizing the PMT correlated one which is available in
> get_device_crosstime_stamp().

AFAICT that was the *only* one he was exposing, wasn't it? The vmclock
driver literally did expose the cycle count used to create the device
timestamp, which is equivalent to PTM and looked correct for that part?

> Can we please stop creating specialized interfaces and instead make them
> generic, so they can be used for everything?

Of course.

> Then you can go and extend the posix-timer interface with
> clock_set_time_reference() (or whatever name we come up with) and
> provide the functionality for all steerable clocks. That'd allow chronyd
> to completely ignore the kernel side NTP PLL and do everything in user
> space. That obviously needs some thought and input from the chrony
> folks, but that's a long term useful solution and not some 'scratch my
> itch' side channel.

Yeah, that's a neat idea. I deliberately hadn't even *proposed* a
userspace API for that at all yet; for the timekeeping part I'm just
working on the basic *concepts* and the accounting fixes that make it
all actually work, with a hack to unconditionally call it directly from
vmclock for now.

In order to solicit exactly that feedback and design a long term
solution that works for everyone, before going too far down any
particular implementation path.

I like clock_set_time_reference(). I'll have a play and see what I can
come up with. It would want to carry error bounds information too.

Having a clock_get_time_reference() would be nice too for QEMU to use,
but that would just be a snapshot and wouldn't get updated when the
clock is adjusted. While the /dev/vmclock_host thing I have in my tree
right now can at least use a gtod notifier and the userspace device is
pollable. And it can export everything we need in one go. More thought
required on that one... but I'm very keen *not* to let that one get
forgotten, because I want this to work optimally for the general case
of QEMU running on a standard general purpose host, not *only* the
dedicated hosting setup where userspace is prepared to do all the work.

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