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 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 Date: Thu, 07 Mar 2024 14:02:07 +0000 [thread overview] Message-ID: <0e21e3e2be26acd70b5575b9932b3a911c9fe721.camel@infradead.org> (raw) In-Reply-To: <20231218073849.35294-1-peter.hilber@opensynergy.com> [-- Attachment #1: Type: text/plain, Size: 3415 bytes --] On Mon, 2023-12-18 at 08:38 +0100, Peter Hilber wrote: > RFC v3 updates > -------------- > > This series implements a driver for a virtio-rtc device conforming to spec > RFC v3 [1]. It now includes an RTC class driver with alarm, in addition to > the PTP clock driver already present before. > > This patch series depends on the patch series "treewide: Use clocksource id > for get_device_system_crosststamp()" [3]. Pull [4] to get the combined > series on top of mainline. > > Overview > -------- > > This patch series adds the virtio_rtc module, and related bugfixes. The > virtio_rtc module implements a driver compatible with the proposed Virtio > RTC device specification [1]. The Virtio RTC (Real Time Clock) device > provides information about current time. The device can provide different > clocks, e.g. for the UTC or TAI time standards, or for physical time > elapsed since some past epoch. Hm, should we allow UTC? If you tell me the time in UTC, then (sometimes) I still don't actually know what the time is, because some UTC seconds occur twice. UTC only makes sense if you provide the TAI offset, surely? Should the virtio_rtc specification make it mandatory to provide such? Otherwise you're just designing it to allow crappy hypervisors to expose incomplete information. > PTP clock interface > ------------------- > > virtio_rtc exposes clocks as PTP clocks to userspace, similar to ptp_kvm. > If both the Virtio RTC device and this driver have special support for the > current clocksource, time synchronization programs can use > cross-timestamping using ioctl PTP_SYS_OFFSET_PRECISE2 aka > PTP_SYS_OFFSET_PRECISE. Similar to ptp_kvm, system time synchronization > with single-digit ns precision is possible with a quiescent reference clock > (from the Virtio RTC device). This works even when the Virtio device > response is slow compared to ptp_kvm hypercalls. Is PTP the right mechanism for this? As I understand it, PTP is a way to precisely synchronize one clock with another. But in the case of virt guests synchronizing against the host, it isn't really *another* clock. It really is the *same* underlying clock. As the host clock varies with temperature, for example, so does the guest clock. The only difference is an offset and (on x86 perhaps) a mathematical scaling of the frequency. I was looking at this another way, when I came across this virtio-rtc work. My idea was just for the hypervisor to expose its own timekeeping information — the counter/TSC value and TAI time at a given moment, frequency of the counter, and the precision of both that frequency (±PPM) and the TAI timestamp (±µs). By putting that in a host/guest shared data structure with a seqcount for lockless updates, we can update it as time synchronization on the host is refined, and we can even cleanly handle live migration where the guest ends up on a completely different host. It allows for use cases which *really* care (e.g. timestamping financial transactions) to ensure that there is never even a moment of getting *wrong* timestamps if they haven't yet resynced after a migration. Now I'm trying to work out if I should attempt to reconcile with your existing virtio-rtc work, or just decide that virtio-rtc isn't trying to solve the actual problem that we have, and go ahead with something different... ? [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 5965 bytes --]
WARNING: multiple messages have this Message-ID (diff)
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 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 Date: Thu, 07 Mar 2024 14:02:07 +0000 [thread overview] Message-ID: <0e21e3e2be26acd70b5575b9932b3a911c9fe721.camel@infradead.org> (raw) In-Reply-To: <20231218073849.35294-1-peter.hilber@opensynergy.com> [-- Attachment #1.1: Type: text/plain, Size: 3415 bytes --] On Mon, 2023-12-18 at 08:38 +0100, Peter Hilber wrote: > RFC v3 updates > -------------- > > This series implements a driver for a virtio-rtc device conforming to spec > RFC v3 [1]. It now includes an RTC class driver with alarm, in addition to > the PTP clock driver already present before. > > This patch series depends on the patch series "treewide: Use clocksource id > for get_device_system_crosststamp()" [3]. Pull [4] to get the combined > series on top of mainline. > > Overview > -------- > > This patch series adds the virtio_rtc module, and related bugfixes. The > virtio_rtc module implements a driver compatible with the proposed Virtio > RTC device specification [1]. The Virtio RTC (Real Time Clock) device > provides information about current time. The device can provide different > clocks, e.g. for the UTC or TAI time standards, or for physical time > elapsed since some past epoch. Hm, should we allow UTC? If you tell me the time in UTC, then (sometimes) I still don't actually know what the time is, because some UTC seconds occur twice. UTC only makes sense if you provide the TAI offset, surely? Should the virtio_rtc specification make it mandatory to provide such? Otherwise you're just designing it to allow crappy hypervisors to expose incomplete information. > PTP clock interface > ------------------- > > virtio_rtc exposes clocks as PTP clocks to userspace, similar to ptp_kvm. > If both the Virtio RTC device and this driver have special support for the > current clocksource, time synchronization programs can use > cross-timestamping using ioctl PTP_SYS_OFFSET_PRECISE2 aka > PTP_SYS_OFFSET_PRECISE. Similar to ptp_kvm, system time synchronization > with single-digit ns precision is possible with a quiescent reference clock > (from the Virtio RTC device). This works even when the Virtio device > response is slow compared to ptp_kvm hypercalls. Is PTP the right mechanism for this? As I understand it, PTP is a way to precisely synchronize one clock with another. But in the case of virt guests synchronizing against the host, it isn't really *another* clock. It really is the *same* underlying clock. As the host clock varies with temperature, for example, so does the guest clock. The only difference is an offset and (on x86 perhaps) a mathematical scaling of the frequency. I was looking at this another way, when I came across this virtio-rtc work. My idea was just for the hypervisor to expose its own timekeeping information — the counter/TSC value and TAI time at a given moment, frequency of the counter, and the precision of both that frequency (±PPM) and the TAI timestamp (±µs). By putting that in a host/guest shared data structure with a seqcount for lockless updates, we can update it as time synchronization on the host is refined, and we can even cleanly handle live migration where the guest ends up on a completely different host. It allows for use cases which *really* care (e.g. timestamping financial transactions) to ensure that there is never even a moment of getting *wrong* timestamps if they haven't yet resynced after a migration. Now I'm trying to work out if I should attempt to reconcile with your existing virtio-rtc work, or just decide that virtio-rtc isn't trying to solve the actual problem that we have, and go ahead with something different... ? [-- Attachment #1.2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 5965 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ 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-07 14:02 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 ` David Woodhouse [this message] 2024-03-07 14:02 ` [RFC PATCH v3 0/7] Add virtio_rtc module and related changes 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 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=0e21e3e2be26acd70b5575b9932b3a911c9fe721.camel@infradead.org \ --to=dwmw2@infradead.org \ --cc=a.zummo@towertech.it \ --cc=alexandre.belloni@bootlin.com \ --cc=christopher.s.hall@intel.com \ --cc=daniel.lezcano@linaro.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=peter.hilber@opensynergy.com \ --cc=richardcochran@gmail.com \ --cc=ridouxj@amazon.com \ --cc=sboyd@kernel.org \ --cc=tglx@linutronix.de \ --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.