On Fri, 2026-05-15 at 16:40 +0000, Arthur Kiyanovski wrote: > Implement the gettimexattrs64 and getcrosststampattrs callbacks in the > ptp_vmclock driver to provide clock quality attributes through the new > PTP_SYS_OFFSET_EXTENDED_ATTRS and PTP_SYS_OFFSET_PRECISE_ATTRS ioctls. > > The ptp_vmclock device exposes: > - error_bound: Derived from time_maxerror_nanosec, accumulated with > counter frequency error (counter_period_maxerror_rate_frac_sec) over > elapsed counter ticks > - clock_status: Mapped from the device's clock_status field > - timescale: Determined from time_type (UTC, TAI, monotonic, etc.) > > The legacy ioctls return -EINVAL when clock_status is UNRELIABLE since > they have no way to communicate clock state to userspace. The attrs > ioctls have a status field for this purpose, so they treat UNRELIABLE > as success and let userspace check the status field. > > To avoid a race where the hypervisor could update clock_status between > the timestamp call and the UNRELIABLE check, the clock state is captured > inside the seq_count loop for a consistent snapshot with the timestamp. > > Signed-off-by: Arthur Kiyanovski <[email protected]>
Looks sane, although I haven't tested it. I think I recall pointing you at a QEMU hack which will export *some* actual hardcoded time information through vmclock, which is what I'd always tested the guest with so far. In the last week or so I've posted host kernel and QEMU support to expose *actual* host timekeeping to the guests, which might be useful to do some more comprehensive testing? Reviewed-by: David Woodhouse <[email protected]>
smime.p7s
Description: S/MIME cryptographic signature
