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. > 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. > 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 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. > 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? Thanks, Richard
