On Sun, 2025-08-03 at 16:51 -0700, Julien Ridoux wrote:

quoted

On 7/28/25, 7:28 AM, "Miroslav Lichvar"
<mlichvar@redhat.com <mailto:mlichvar@redhat.com>> wrote:

On Thu, Jul 24, 2025 at 02:56:56PM +0300, David Arinzon wrote:

quoted

The proposed PTP_SYS_OFFSET_EXTENDED_TRUSTED ioctl offers the
same timestamps as the PTP_SYS_OFFSET_EXTENDED ioctl, but extends
it with a measurement of the PHC device clock accuracy and the
synchronization status. This supports two objectives.

I have a slight issue with the naming of this new ioctl. TRUSTED
implies to me the other supported ioctls are not to be trusted
for some reason, but that's not the case, right? It's just more
information provided, i.e. it's extended once again. Would
PTP_SYS_OFFSET_EXTENDED3 or PTP_SYS_OFFSET_EXTENDED_ATTRS not work
better?

That's a fair call. The ioctl can be renamed to
PTP_SYS_OFFSET_EXTENDED_ATTRS

While we're talking about extending the userspace API... I think I'd
also like a way to use the actual hardware counter (TSC, arch timer) as
the reference clockid instead of CLOCK_MONOTONIC etc. 

In a hosting environment, I barely even care about calibrating the host
kernel's timekeeping against the external time reference. What I *do*
care about calibrating is the hardware counter, so that it can be
correctly advertised to guests through a vmclock device.

Using vmclock and simply advertising the relationship between the
hardware counter and precision time, makes *so* much more sense than
having hundreds of virtual guests on the same machine all performing
the *same* calibration of precisely the same underlying counter, each
of them potentially experiencing latency of measurements due to steal
time while they do so.