Received-SPF: pass (google.com: domain of linux-kernel+bounces-102345-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Wed, 13 Mar 2024 18:18:31 +0000
From: David Woodhouse <dwmw2@infradead.org>
To: Peter Hilber <peter.hilber@opensynergy.com>, linux-kernel@vger.kernel.org,
 virtualization@lists.linux.dev, virtio-dev@lists.oasis-open.org,
 linux-arm-kernel@lists.infradead.org, linux-rtc@vger.kernel.org,
 "virtio-comment@lists.oasis-open.org" <virtio-comment@lists.oasis-open.org>
CC: "Christopher S. Hall" <christopher.s.hall@intel.com>,
 Jason Wang <jasowang@redhat.com>, John Stultz <jstultz@google.com>,
 "Michael S. Tsirkin" <mst@redhat.com>, netdev@vger.kernel.org,
 Richard Cochran <richardcochran@gmail.com>, Stephen Boyd <sboyd@kernel.org>,
 Thomas Gleixner <tglx@linutronix.de>, Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
 Marc Zyngier <maz@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
 Daniel Lezcano <daniel.lezcano@linaro.org>,
 Alessandro Zummo <a.zummo@towertech.it>,
 Alexandre Belloni <alexandre.belloni@bootlin.com>,
 "Ridoux, Julien" <ridouxj@amazon.com>
Subject: Re: [RFC PATCH v3 0/7] Add virtio_rtc module and related changes
User-Agent: K-9 Mail for Android
In-Reply-To: <60607bcc-93c5-4a6f-832d-ea4dbd81178e@opensynergy.com>
References: <20231218073849.35294-1-peter.hilber@opensynergy.com> <0e21e3e2be26acd70b5575b9932b3a911c9fe721.camel@infradead.org> <204c6339-e80d-4a98-8d07-a11eeb729497@opensynergy.com> <667c8d944ce9ea5c570b82b1858a70cc67b2f3e4.camel@infradead.org> <f6940954-334a-458b-af32-f03d8efbe607@opensynergy.com> <57704b2658e643fce30468dffd8c1477607f59fb.camel@infradead.org> <d796d9a5-8eda-4528-a6d8-1c4eba24aa1e@opensynergy.com> <47bf0757de3268c420d2cd3bbffaf5897b67b661.camel@infradead.org> <60607bcc-93c5-4a6f-832d-ea4dbd81178e@opensynergy.com>
Message-ID: <89268C36-E8FB-4A17-8F81-1DED4BF47400@infradead.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 13 March 2024 17:50:48 GMT, Peter Hilber <peter=2Ehilber@opensynergy=2Ec=
om> wrote:
>On 13=2E03=2E24 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?=20
>
>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=
=2E
>
>Where we might differ is as to whether the Virtio clock *for every
>implementation* has to be *continuously* accurate w=2Er=2Et=2E a time sta=
ndard,
>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=2E

That makes sense, but remember I don't just want {X, Y, Z} but *also* the =
error bounds of =C2=B1deltaY and =C2=B1deltaZ too=2E

So your example just boils down to "I'm calling it UTC, and it's really pr=
ecise, but we make no promises about its *accuracy*"=2E And that's fine=2E

>Also, cf=2E ptp_kvm, which AFAIU doesn't address leap seconds at all=2E=
=2E=2E

KVM is not an exemplar of good time practices=2E=20
Not in *any* respect :)

>With your described use case the UTC_SMEARED clock should of course not b=
e
>used=2E The UTC_SMEARED clock would get a distinct name through udev, lik=
e
>/dev/ptp_virtio_utc_smeared, so the incompatibility could at least be
>detected=2E

As long as it's clear to all concerned that this is fundamentally not usab=
le as an accurate time source, and is only for the local-sync case you desc=
ribed, sure=2E

>> 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=2E To resolve that
>> ambiguity needs a leap indicator and/or tai_offset field=2E
>
>I agree that virtio-rtc should communicate this=2E 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 expos=
e time precisely and unambiguously, it's less important if the Linux kernel=
 *today* can use that=2E Although of course we should strive for that=2E Le=
t's be=2E=2E=2Ewell, *unambiguous*, I suppose=2E=2E=2E that we've changed t=
opics to discuss that though=2E

>As for PTP clocks:
>
>- It doesn't fit into the ioctl PTP_SYS_OFFSET_PRECISE2=2E
>
>- The clock_adjtime(2) tai_offset and return value could be set (if
>  upstream will accept this)=2E Would this help? As discussed, user space
>  would need to interpret this (and currently no dynamic POSIX clock sets
>  this)=2E

Hm, maybe?


>>> I think I can add a SHOULD requirement which vaguely refers to vCPU 0,=
 or
>>> boot vCPU=2E But the Virtio device is not necessarily hosted by a hype=
rvisor,
>>> so the device might not even know which vCPUs there are=2E E=2Eg=2E th=
ere is even
>>> interest to make virtio-rtc work as part of the virtio-net device (whi=
ch
>>> might be implemented in hardware)=2E
>>=20
>> Sure, but those implementations aren't going to offer the TSC pairing
>> at all, are they?
>>=20
>
>They could offer an Intel ART pairing (some physical PTP NICs are already
>doing this, look for the convert_art_to_tsc() users)=2E

Right, but isn't that software's problem? The time pairing is defined agai=
nst the ART in that case=2E