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

[Thomas Gleixner <tglx@kernel.org>]

On Fri, May 22 2026 at 11:01, David Woodhouse wrote:
> On Fri, 2026-05-22 at 10:02 +0200, Thomas Gleixner wrote:
> Obviously. But to take a PoC and then do that thought and turn it into
> something we can use, it still needs a Co-developed-by: and thus a
> Signed-off-by: if you would be so kind.

  git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git timers/ptp/timekeeping

is the work in progress state as of now. I'm not going to touch it in
the next days and it's still in a rough uncompiled state. It lacks quite
some change logs and the last patch needs to be split up.

I'll go and have a look next week so that I can rethink the approach
with a clear mind.
> Heh, the 'made up world' of which you speak is KVM. The older KVM PTP
> drivers get a CSID_X86_TSC or CSID_ARM_ARCH_COUNTER value too.
>
> And they *use* it... and wait, get_device_system_crosststamp() already
> *does* require the device to generate a system_counterval_t, so your
> nightmare world where driver authors might pull it out of their
> posterior *already* exists, doesn't it?

It exists. Because get_device_system_crosststamp() does _NOT_ propagate
the counter values after converting them to actual TSC values. The half
baked snipped I provided you earlier does exactly that (but wrong). The
version in the git branch should be halfways functional.

> And we have things like stmmac which already populate it using
> CSID_X86_ART.

It does not populate back into PTP land. That's a
get_device_system_crosststamp() internal handshake where the driver
callback provides the PTM time stamp and tells the core which clock
source it is based on. The core converts it to the system clocksource
cycles, e.g. ART to TSC, and then calculates MONO_RAW and REALTIME from
it, optionally with an extra snapshot that allows historical
interpolation for devices where the timestamp retrieval takes ages.

> So at least for PTP_SYS_OFFSET_PRECISE, isn't Arthur's patch literally
> only exporting the same counter values that the driver *already*
> creates? I'm not quite sure why we have all these histrionics about
> drivers not being able to create those reliably?

The driver reads it from the hardware but it does not know how to
convert them back to TSC or anything else. For the driver it's an opaque
piece of data which it read out of a register or got retrieved through a
firmware query.

> Yes, there's plenty to improve as discussed, and we should probably
> have get_device_system_crosststamp() copy the values from the
> system_counterval on its local stack into the system_device_crosststamp
> rather than asking the driver to pass it back through separate fields
> in the attributes.

See the original snippet and the git tree how that is done by extending
the cross time stamp structure and storing all the information there,
which is what PTP hands in:

      system_cross_timestamp sct;

      ptp->info->getcrosstimestamp(..., &sct)
         driver_getcrosstimestamp(...., *sct) {
           get_device_system_crosststamp(callback, context, ..., sct) {
              system_counterval_t scv;
              ktime_t device_time;

              do {
              	...
                callback(&device_time, &scv, context) {
                   read_snapshot(&pch_time, &ptm_time);

                   *device_time = munge(pch_time);
                   scv->cycles = ptm_time;
                   scv->cs_id = ART;
		}
                ....
                cs_cycles = convert_ptm_to_cs(scv.cycles, scv.cs_id);

                real = timekeeping_convert_to_real(cs_cycles);
                raw = timekeeping_convert_to_raw(cs_cycles);

              } while (seq_retry());

              sct->device = device_time;
              sct->real = real;
              sct->raw = raw;
           }

So the new parts are that system_cross_timestamp gains a
system_counter_val and get_device_system_crosststamp() fills that in:

              sct->counter.cycles = cs_cycles;
              sct->counter.cs_id = csid;

On X86 you get the TSC cycles (derived from ART) and CSID_X86_TSC.

That goes all the way back to the PTP layer. Which means magically _all_
existing users of get_device_system_crosststamp() will provide that data
out of the box.

The existing PRECISE usecase will just ignore sct.counter. Your new
stuff can use it and fill in the related attributes in the user space
attr struct.

This raises an interesting question. Must any of the existing PTM using
drivers mplement that new extended getcrosstimestampattr() callback, in
order to expose the cycles/csid in attr or can you fallback to the
existing callback and have the rest of the fields 0?

Same question arises if you change the pre/post timestamp helpers to
utilize ktime_get_snapshot_id(). All existing drivers which use them
will then automatically retrieve cs_cycles/cs_id.

The other change I did to get_device_system_crosststamp() is to let the
PTP core hand in the clock ID, so it can retrieve either REALTIME or AUX
clocks, which enables the whole AUX world to utilize PTM too once the
PTP IOCTL is updated accordingly.

Can you please make the new PTP_SYS_OFFSET_PRECISE_ATTRS and
PTP_SYS_OFFSET_EXTENDED_ATTRS so that user space can convey the CLOCK
ID, like it does today with PTP_SYS_OFFSET_EXTENDED?

Thanks,

        tglx