Messages in this thread | | | Date | Wed, 13 Mar 2024 18:18:31 +0000 | From | David Woodhouse <> | Subject | Re: [RFC PATCH v3 0/7] Add virtio_rtc module and related changes |
| |
On 13 March 2024 17:50:48 GMT, Peter Hilber <peter.hilber@opensynergy.com> wrote: >On 13.03.24 13:45, David Woodhouse wrote: >> Surely the whole point of this effort is to provide guests with precise >> and *unambiguous* knowledge of what the time is? > >I would say, a fundamental point of this effort is to enable such >implementations, and to detect if a device is promising to support this. > >Where we might differ is as to whether the Virtio clock *for every >implementation* has to be *continuously* accurate w.r.t. a time standard, >or whether *for some implementations* it could be enough that all guests in >the local system have the same, precise local notion of time, which might >be off from the actual time standard.
That makes sense, but remember I don't just want {X, Y, Z} but *also* the error bounds of ±deltaY and ±deltaZ too.
So your example just boils down to "I'm calling it UTC, and it's really precise, but we make no promises about its *accuracy*". And that's fine.
>Also, cf. ptp_kvm, which AFAIU doesn't address leap seconds at all...
KVM is not an exemplar of good time practices. Not in *any* respect :)
>With your described use case the UTC_SMEARED clock should of course not be >used. The UTC_SMEARED clock would get a distinct name through udev, like >/dev/ptp_virtio_utc_smeared, so the incompatibility could at least be >detected.
As long as it's clear to all concerned that this is fundamentally not usable as an accurate time source, and is only for the local-sync case you described, sure.
>> Using UTC is bad enough, because for a UTC timestamp in the middle of a >> leap second the guest can't know know *which* occurrence of that leap >> second it is, so it might be wrong by a second. To resolve that >> ambiguity needs a leap indicator and/or tai_offset field. > >I agree that virtio-rtc should communicate this. The question is, what >exactly, and for which clock read request?
Are we now conflating software architecture (and Linux in particular) with "hardware" design?
To a certain extent, as long as the virtio-rtc device is designed to expose time precisely and unambiguously, it's less important if the Linux kernel *today* can use that. Although of course we should strive for that. Let's be...well, *unambiguous*, I suppose... that we've changed topics to discuss that though.
>As for PTP clocks: > >- It doesn't fit into the ioctl PTP_SYS_OFFSET_PRECISE2. > >- The clock_adjtime(2) tai_offset and return value could be set (if > upstream will accept this). Would this help? As discussed, user space > would need to interpret this (and currently no dynamic POSIX clock sets > this).
Hm, maybe?
>>> I think I can add a SHOULD requirement which vaguely refers to vCPU 0, or >>> boot vCPU. But the Virtio device is not necessarily hosted by a hypervisor, >>> so the device might not even know which vCPUs there are. E.g. there is even >>> interest to make virtio-rtc work as part of the virtio-net device (which >>> might be implemented in hardware). >> >> Sure, but those implementations aren't going to offer the TSC pairing >> at all, are they? >> > >They could offer an Intel ART pairing (some physical PTP NICs are already >doing this, look for the convert_art_to_tsc() users).
Right, but isn't that software's problem? The time pairing is defined against the ART in that case.
| |