Re: [PATCH v7 4/4] virtio-rtc: Add normative statements for alarm feature

[Matias Ezequiel Vara Larsen <mvaralar@redhat.com>]

On Thu, Feb 20, 2025 at 06:06:38PM +0100, Peter Hilber wrote:
> On Wed, Feb 19, 2025 at 04:36:14PM +0100, Matias Ezequiel Vara Larsen wrote:
> > On Thu, Feb 13, 2025 at 07:14:30PM +0100, Peter Hilber wrote:
> > > On Tue, Feb 11, 2025 at 01:33:42PM +0100, Matias Ezequiel Vara Larsen wrote:
> > > > On Thu, Jan 23, 2025 at 11:16:15AM +0100, Peter Hilber wrote:
> > > > > Add the normative statements for the alarm feature added previously.
> > > > > 
> > > > > Signed-off-by: Peter Hilber <quic_philber@quicinc.com>
> > > > > ---
> > > > > 
> > > > > Notes:
> > > > >     v7:
> > > > >     
> > > > >     - Remove inadvertent v6 changes, which should have been part of
> > > > >       preceding patches.
> > > > >     
> > > > >     v4:
> > > > >     
> > > > >     - Update normative statements to match v4 changes to non-normative
> > > > >       statements (patch 3).
> > > > >     
> > > > >     - Driver should read clock to confirm that alarm has expired.
> > > > >     
> > > > >     - Formatting and wording improvements.
> > > > > 
> > > > >  device-types/rtc/description.tex        | 157 ++++++++++++++++++++++++
> > > > >  device-types/rtc/device-conformance.tex |   4 +
> > > > >  device-types/rtc/driver-conformance.tex |   2 +
> > > > >  3 files changed, 163 insertions(+)
> > > > > 
> 
> [...]
> 
> > > > > +
> > > > > +If a clock C steps to a time previous to C's alarm time, the device MUST
> > > > > +stop serving any previous alarm expiration event for C, within a grace
> > > > > +period.
> > > > > +
> > > > > +If an alarm expiration event happens for clock C, the device MUST stop
> > > > > +serving any previous alarm expiration event for C, within a grace
> > > > > +period.
> > > > > +
> > > > > +If the device is currently serving an alarm expiration event E, the
> > > > > +device MUST send a single VIRTIO_RTC_NOTIF_ALARM notification for E, as
> > > > > +soon as an alarmq buffer is available for this purpose.
> > > > > +
> > > > > +While the device is serving an alarm expiration event, the device MAY
> > > > > +execute implementation-specific alarm actions.
> > > > > +

Does not `serving` mean also that the device execute
implementation-specific alarm actions? Besides notifying the guest when
an alarm has expired, is not any other action or device behavior
implementation-specific and then not constrained by the spec?

> > > > > +The device MAY ignore the device status when executing
> > > > > +implementation-specific alarm actions.
> > > > > +
> > > > > +The device MAY ignore whether VIRTIO_RTC_F_ALARM was negotiated when
> > > > > +executing implementation-specific alarm actions.
> > > 
> > 
> > I wonder if these last three requirements are needed or we can just drop
> > them.
> > 
> > Matias
> > 
> 
> The intent of these requirements is to clarify that this is legitimate
> and expected behavior of the device. I can drop them if this is
> considered unnecessary as normative requirements. Or maybe one
> requirement would be enough:
> 
> 	While the device is not serving an alarm expiration event, the
> 	device MUST NOT execute implementation-specific alarm actions.