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

[David Woodhouse]

On Fri, 2026-05-22 at 17:28 +0200, Thomas Gleixner wrote:
> 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.

Thanks. I'll have a play with it. With ptp_read_system_p{re,ost}ts()
also populating pre/post system_counterval_t fields in the struct
ptp_system_timestamp, I can do a bit more cleanup of vmclock than you
have there by using them; I'll work that in.

> > 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.

Ah, I see it. convert_base_to_cs().


> 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.

Perfect.

> 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.

Taking those in reverse order... yes, this means that with a new
variant of PTP_SYS_OFFSET_EXTENDED, userspace can see actual counter
values even for the system parts of those ABA timestamps, even for non-
PTM clocks, and discipline the TSC/archcounter against the external
clock.

Currently I have userspace which literally does rdtsc() either side of
calling the ioctl :)

And PTM devices can be used with PTP_SYS_OFFSET_PRECISE, which goes
through get_device_system_crosststamp() as described, and all just
works? It's just that we now allow userspace to *see* the counter value
that the driver was already generating.

So to your questions: although there's new userspace ioctl support, the
*drivers* don't need any modification for that (as long as they use the
standard prets/postts helpers).


The remaining question is the device timestamp part (the 'B' in the ABA
sandwich) for PTP_SYS_OFFSET_EXTENDED with PTM-capable drivers. Should
that get a counterval?

I don't have a strong opinion. On one hand we'd have to find a way to
convert it from PTM for devices where it actually *is* PTM, and that's
what PTP_SYS_OFFSET_PRECISE is *for*.

But on the other hand, can't the conversion be a whole lot simpler than
get_device_system_crosststamp() because it's not actually dealing with
any timekeepers; it's basically only invoking convert_base_to_cs()?

And the ioctl should support it *all* but just have a clear way of
indicating that any of the optional fields including the attrs are
*not* populated (or use 0/max values maybe?).

So no, I don't think any driver *has* to add any attr support in order
to expose counter values to userspace. The only reason I asked Arthur
to mix those things up was for the *userspace* API, to avoid adding yet
another ioctl over and over again. And now I feel bad for doing so :)

> 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?

Ack (on Arthur's behalf).

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