On Wed, Dec 25, 2024 at 04:42:14PM -0800, Richard Cochran wrote: > On Mon, Dec 23, 2024 at 07:13:46PM +0100, Peter Hilber wrote: > > > 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. > > I thought that the whole point of using a VM is to isolate the guests > from each other and the host. What you describe is a promiscuous > coupling between guest and host, and the kernel shouldn't be in > the business of supporting such behavior. > Why? There is already ptp_kvm etc. in the kernel. Would it be more acceptable to just announce leap seconds, but not whether to smear? > > Also, the administrative > > configuration choice may change over the lifetime of a system. > > Right, which is why we should keep those choices out of kernel space. > Kernel provides mechanism, not policy. > As discussed, the policy would be forwarded, not determined, by the kernel. If the policy would be forwarded via NTP (by the NTP server smearing or not smearing leap seconds), this would have the following disadvantages: - need to use an NTP server just for announcing leap seconds - redundancy of serving time both via NTP and via PTP clocks (for better precision) - no awareness about leap seconds in case of smearing. > > 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. > > Again, I don't think the kernel should be the solution to guests that > lack networking. Instead, the place to fix the problem is at the > root, namely in the guests. > I do not understand. Is the point that guests should decide through another channel about leap second smearing? > > 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. > > Overall, I don't trust devices to tell the truth about their > qualities. But putting that aside, we would need to see some kind of > commonality in hardware implementation to advertise their metrics. > However, AFAICT there is no such industry practice on the market. > I hope there will be some feedback from third parties (at least related to virtualization). > > 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. > > Again, host user space shouldn't misuse the kernel to share random > metrics with guest user space. Isn't there another way to share such > info from host to guest? > For sure. But the aim of this proposal is to have an interoperable time synchronization solution for VMs through a Virtio device. So the idea is to include metrics, if a consensus on their usefulness can be reached. AFAIU it is difficult to bypass the kernel for Virtio devices. Thanks for the discussion, Peter
