From: Peter Hilber <peter.hilber@opensynergy.com> To: David Woodhouse <dwmw2@infradead.org>, 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>, Cornelia Huck <cohuck@redhat.com> Subject: Re: [RFC PATCH v3 0/7] Add virtio_rtc module and related changes Date: Thu, 14 Mar 2024 11:13:37 +0100 [thread overview] Message-ID: <2eb5a616-eeb3-446a-85fd-fff376c15f55@opensynergy.com> (raw) In-Reply-To: <89268C36-E8FB-4A17-8F81-1DED4BF47400@infradead.org> Now CC'ing the previous commenters to the virtio-rtc spec draft, since this discussion is mostly about the spec, and the Virtio mailing lists still seem to be in a migration hiatus... On 13.03.24 19:18, David Woodhouse wrote: > 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 Virtio is extensible (unlike hardware), my approach is to mostly specify only what also has a PoC user and a use case. >> 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. My point was that such a device would then not necessarily have an idea what vCPU 0 is. But let's just say that this will be phrased as a SHOULD best-effort requirement anyway. Thanks for the comments, Peter
WARNING: multiple messages have this Message-ID (diff)
From: Peter Hilber <peter.hilber@opensynergy.com> To: David Woodhouse <dwmw2@infradead.org>, 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>, Cornelia Huck <cohuck@redhat.com> Subject: Re: [RFC PATCH v3 0/7] Add virtio_rtc module and related changes Date: Thu, 14 Mar 2024 11:13:37 +0100 [thread overview] Message-ID: <2eb5a616-eeb3-446a-85fd-fff376c15f55@opensynergy.com> (raw) In-Reply-To: <89268C36-E8FB-4A17-8F81-1DED4BF47400@infradead.org> Now CC'ing the previous commenters to the virtio-rtc spec draft, since this discussion is mostly about the spec, and the Virtio mailing lists still seem to be in a migration hiatus... On 13.03.24 19:18, David Woodhouse wrote: > 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 Virtio is extensible (unlike hardware), my approach is to mostly specify only what also has a PoC user and a use case. >> 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. My point was that such a device would then not necessarily have an idea what vCPU 0 is. But let's just say that this will be phrased as a SHOULD best-effort requirement anyway. Thanks for the comments, Peter _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-03-14 10:13 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-12-18 7:38 [virtio-dev] [RFC PATCH v3 0/7] Add virtio_rtc module and related changes Peter Hilber 2023-12-18 7:38 ` Peter Hilber 2023-12-18 7:38 ` Peter Hilber 2023-12-18 7:38 ` [RFC PATCH v3 1/7] timekeeping: Fix cross-timestamp interpolation on counter wrap Peter Hilber 2024-02-19 16:35 ` [tip: timers/core] " tip-bot2 for Peter Hilber 2023-12-18 7:38 ` [RFC PATCH v3 2/7] timekeeping: Fix cross-timestamp interpolation corner case decision Peter Hilber 2024-02-19 16:35 ` [tip: timers/core] " tip-bot2 for Peter Hilber 2023-12-18 7:38 ` [RFC PATCH v3 3/7] timekeeping: Fix cross-timestamp interpolation for non-x86 Peter Hilber 2024-02-19 16:35 ` [tip: timers/core] " tip-bot2 for Peter Hilber 2023-12-18 7:38 ` [virtio-dev] [RFC PATCH v3 4/7] virtio_rtc: Add module and driver core Peter Hilber 2023-12-18 7:38 ` Peter Hilber 2023-12-18 7:38 ` Peter Hilber 2023-12-18 7:38 ` [virtio-dev] [RFC PATCH v3 5/7] virtio_rtc: Add PTP clocks Peter Hilber 2023-12-18 7:38 ` Peter Hilber 2023-12-18 7:38 ` Peter Hilber 2023-12-18 7:38 ` [virtio-dev] [RFC PATCH v3 6/7] virtio_rtc: Add Arm Generic Timer cross-timestamping Peter Hilber 2023-12-18 7:38 ` Peter Hilber 2023-12-18 7:38 ` Peter Hilber 2023-12-18 7:38 ` [virtio-dev] [RFC PATCH v3 7/7] virtio_rtc: Add RTC class driver Peter Hilber 2023-12-18 7:38 ` Peter Hilber 2024-03-08 17:03 ` Alexandre Belloni 2024-03-11 18:28 ` Peter Hilber 2024-03-11 19:46 ` Alexandre Belloni 2024-03-13 9:13 ` Peter Hilber 2024-03-07 14:02 ` [RFC PATCH v3 0/7] Add virtio_rtc module and related changes David Woodhouse 2024-03-07 14:02 ` David Woodhouse 2024-03-08 10:32 ` Peter Hilber 2024-03-08 10:32 ` Peter Hilber 2024-03-08 12:33 ` David Woodhouse 2024-03-08 12:33 ` David Woodhouse 2024-03-11 18:24 ` Peter Hilber 2024-03-11 18:24 ` Peter Hilber 2024-03-12 17:15 ` David Woodhouse 2024-03-12 17:15 ` David Woodhouse 2024-03-13 9:45 ` Peter Hilber 2024-03-13 9:45 ` Peter Hilber 2024-03-13 11:18 ` Alexandre Belloni 2024-03-13 11:18 ` Alexandre Belloni 2024-03-13 12:29 ` David Woodhouse 2024-03-13 12:29 ` David Woodhouse 2024-03-13 12:58 ` Alexandre Belloni 2024-03-13 12:58 ` Alexandre Belloni 2024-03-13 14:06 ` David Woodhouse 2024-03-13 14:06 ` David Woodhouse 2024-03-13 14:50 ` Alexandre Belloni 2024-03-13 14:50 ` Alexandre Belloni 2024-03-13 20:12 ` Andrew Lunn 2024-03-13 20:12 ` Andrew Lunn 2024-03-14 9:13 ` Peter Hilber 2024-03-14 9:13 ` Peter Hilber 2024-03-13 17:50 ` Peter Hilber 2024-03-13 17:50 ` Peter Hilber 2024-03-13 14:15 ` Peter Hilber 2024-03-13 14:15 ` Peter Hilber 2024-03-13 12:45 ` David Woodhouse 2024-03-13 12:45 ` David Woodhouse 2024-03-13 17:50 ` Peter Hilber 2024-03-13 17:50 ` Peter Hilber 2024-03-13 18:18 ` David Woodhouse 2024-03-13 18:18 ` David Woodhouse 2024-03-14 10:13 ` Peter Hilber [this message] 2024-03-14 10:13 ` Peter Hilber 2024-03-14 14:19 ` David Woodhouse 2024-03-14 14:19 ` David Woodhouse 2024-03-19 13:47 ` Peter Hilber 2024-03-19 13:47 ` Peter Hilber 2024-03-20 17:22 ` David Woodhouse 2024-03-20 17:22 ` David Woodhouse
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=2eb5a616-eeb3-446a-85fd-fff376c15f55@opensynergy.com \ --to=peter.hilber@opensynergy.com \ --cc=a.zummo@towertech.it \ --cc=alexandre.belloni@bootlin.com \ --cc=christopher.s.hall@intel.com \ --cc=cohuck@redhat.com \ --cc=daniel.lezcano@linaro.org \ --cc=dwmw2@infradead.org \ --cc=jasowang@redhat.com \ --cc=jstultz@google.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-rtc@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=maz@kernel.org \ --cc=mst@redhat.com \ --cc=netdev@vger.kernel.org \ --cc=richardcochran@gmail.com \ --cc=ridouxj@amazon.com \ --cc=sboyd@kernel.org \ --cc=tglx@linutronix.de \ --cc=virtio-comment@lists.oasis-open.org \ --cc=virtio-dev@lists.oasis-open.org \ --cc=virtualization@lists.linux.dev \ --cc=xuanzhuo@linux.alibaba.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.