Received-SPF: pass (google.com: domain of linux-kernel+bounces-103379-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Thu, 14 Mar 2024 15:19:53 +0100
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>, Cornelia Huck <cohuck@redhat.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: <2eb5a616-eeb3-446a-85fd-fff376c15f55@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> <89268C36-E8FB-4A17-8F81-1DED4BF47400@infradead.org> <2eb5a616-eeb3-446a-85fd-fff376c15f55@opensynergy.com>
Message-ID: <9455F710-E38C-45DA-9883-EC034495ADEF@infradead.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 14 March 2024 11:13:37 CET, Peter Hilber <peter=2Ehilber@opensynergy=2Ec=
om> wrote:
>> To a certain extent, as long as the virtio-rtc device is designed to ex=
pose time precisely and unambiguously, it's less important if the Linux ker=
nel *today* can use that=2E Although of course we should strive for that=2E=
 Let's be=2E=2E=2Ewell, *unambiguous*, I suppose=2E=2E=2E that we've change=
d topics to discuss that though=2E
>>=20
>
>As Virtio is extensible (unlike hardware), my approach is to mostly speci=
fy
>only what also has a PoC user and a use case=2E

If we get memory-mapped (X, Y, Z, =C2=B1x, =C2=B1y) I'll have a user and a=
 use case on day one=2E 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 n=
eeds (especially for maintaining accuracy over LM)=2E

My main concern for virto_rtc is that we avoid *ambiguity*=2E Yes, I get t=
hat it's extensible but we don't want a v1=2E0 of the spec, implemented by =
various hypervisors, which still leaves guests not knowing what the actual =
time is=2E That would not be good=2E And even UTC without a leap second ind=
icator has that problem=2E