On Fri, Dec 20, 2024 at 07:19:52AM -0800, Richard Cochran wrote: > On Thu, Dec 19, 2024 at 09:42:03PM +0100, Peter Hilber wrote: > > Ioctl PTP_SYS_OFFSET_PRECISE2 provides cross-timestamping of device time > > and system time. This can be used for virtualization where (virtualization) > > host and guest refer to the same clocksource. It may be preferred to > > indicate UTC time, rather than TAI. It is then useful to indicate when and > > how the host processes UTC leap seconds (stepping or smearing on leap > > seconds), > > If the VM host provides TAI, then the guest may freely derive UTC and > leap seconds on its own. Whether to smear leap seconds or not is > properly an administrative configuration choice in the VM guest. > The precise synchronization of the VM guest with its immediate environment can also be important; a VM guest may depend the decision about leap second smearing on its environment. Also, the administrative configuration choice may change over the lifetime of a system. > Leap seconds are scheduled to be deleted in 2036. If, between now and > then, another one occurs, it will be global event, not determined by a > VM host. The way you find out about leap seconds is through > networking using the NTP (or even just downloading the published list > once in a while). VM clients typically have networking, and so > they can learn about a leap second all by themselves. > The intent is to also support (embedded) VM clients which are themselves not necessarily internetworked, which do not get a lot of maintenance, and which are not guaranteed to get an update within the typically less than 6 months between leap second announcement and occurrence. I will document this in the patch message. > > in particular if the guest is not guaranteed to have an > > up-to-date Time Zone Database or similar. > > Time zones are not connected to leap seconds. > The IANA Time Zone Database includes a leap seconds list. > > Also, a host may have a notion of how accurate its clock is w.r.t. the > > hosts' reference clocks. > > I'm opposed to having device drivers try to claim any kind of clock > quality. All of the clock control, servos, statistics, etc, are done > in user space, and so only user space software can generate meaningful > clock quality metrics. Putting some kind of hand wavy values into > kernel drivers is just plain wrong IMO. I agree that a device driver should not determine clock quality metrics. The intent is that the driver forwards metrics, if such are advertised by the device. These metrics should describe the accuracy etc. of the device itself. The patch message should document this more clearly. The metrics can be determined e.g. by virtualization host user space software. The device driver would just expose the device metrics to user space. Thanks for the feedback, Peter
