Re: [RFC PATCH v3 0/7] Add virtio_rtc module and related changes
From: Peter Hilber
Date: Tue Mar 19 2024 - 09:47:57 EST
While the virtio-comment list is not available, now also CC'ing Parav,
which may be interested in this virtio-rtc spec related discussion thread.
On 14.03.24 15:19, David Woodhouse wrote:
> On 14 March 2024 11:13:37 CET, Peter Hilber <peter.hilber@xxxxxxxxxxxxxxx> wrote:
>>> 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 Virtio is extensible (unlike hardware), my approach is to mostly specify
>> only what also has a PoC user and a use case.
>
> If we get memory-mapped (X, Y, Z, ±x, ±y) I'll have a user and a use case on day one. Otherwise, as I said in my first response, I can go do that as a separate device and decide that virtio_rtc doesn't meet our needs (especially for maintaining accuracy over LM).
We plan to add
- leap second indication,
- UTC-to-TAI offset,
- clock smearing indication (including the noon-to-noon linear smearing
variant which seems to be somewhat popular), and
- clock accuracy indication
to the initial spec and to the PoC implementation.
However, due to resource restrictions, we cannot ourselves add the
memory-mapped clock to the initial spec.
Everyone is very welcome to contribute the memory-mapped clock to the spec,
and I think it might then still make it to the initial version.
>
> My main concern for virto_rtc is that we avoid *ambiguity*. Yes, I get that it's extensible but we don't want a v1.0 of the spec, implemented by various hypervisors, which still leaves guests not knowing what the actual time is. That would not be good. And even UTC without a leap second indicator has that problem.
Agreed. That should be addressed by the above changes.
Best regards,
Peter