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

[David Woodhouse]

On Sun, 2026-05-24 at 14:36 +0200, Thomas Gleixner wrote:
> On Fri, May 22 2026 at 17:23, David Woodhouse wrote:
> > On Fri, 2026-05-22 at 17:28 +0200, Thomas Gleixner wrote:
> > > 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.
> 
> Correct.
> 
> > Currently I have userspace which literally does rdtsc() either side of
> > calling the ioctl :)
> 
> Why am I not surprised? :)

To be fair, I *told* them to do it like that in the short term, knowing
it would annoy me enough to chase up the cycles-in-PTP thing.

And hey, it worked :)

> > 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.
> 
> A new variant of PRECISE

Right.

> > 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).
> 
> Yes.
> 
> > 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?
> 
> PTM-capable driver support cross timestamps, which will with a new
> version of PTP_SYS_OFFSET_PRECISE expose the system counterval. No ABA
> for that as it's hardware latched AB.
> 
> > 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*.
> 
> Correct.
> 
> > 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()?
> 
> But what for? If you have PTM, use PRECISE. There is _zero_ value of
> having pre/post timestamps when the hardware already does the correlated
> precise sampling, no?

The PTM mode and support of PRECISE (or the variant) is currently
fairly esoteric: very few devices support it. So I'm not sure we should
expect generic userspace to always even try.

So there may be some merit in having EXTENDED use the precise hardware
paired timestamp. Maybe we don't necessarily care about returning
*cycles* but if we *do* use a PTM-capable device (and I'm including the
virt TSC-based ones here too), then we kind of want the ABA *all* to be
at the same clock cycle. Which is what I've already done for vmclock.

> > 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?).
> 
> Yes.
> 
> > 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 :)
> 
> I think you can create _one_ data structure variant, which fits both
> EXTENDED_ATTR and PRECISE_ATTR:

 <...>

Yeah, that looks eminently sensible. I've been feeding Arthur
suggestions along those lines but only nudges; you've fleshed it out in
*far* more detail; thanks!

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