Re: [virtio-comment] [RFC PATCH v3 3/4] virtio-rtc: Add alarm feature

[Peter Hilber <peter.hilber@opensynergy.com>]

On 22.12.23 19:57, Cornelia Huck wrote:
> On Mon, Dec 18 2023, Peter Hilber <peter.hilber@opensynergy.com> wrote:
> 
>> Add the VIRTIO_RTC_F_ALARM feature (without normative statements).
>>
>> The intended use case is: A driver needs to react when an alarm time has
>> been reached, but the driver may be in a sleep state or powered off at
>> alarm time. The alarm feature can resume and notify the driver in this
>> case. Alarms may be retained across device resets (including reset on
>> boot).
> 
> Does the driver have some kind of control or information about whether
> alarms are retained? I.e. to start with a clean slate, if wanted.

As of now, the driver can disable the alarm through
VIRTIO_RTC_REQ_SET_ALARM_ENABLED. If the driver does this before making
buffers available to the alarmq, the device behaves like starting with a
clean slate, with two exceptions:

- VIRTIO_RTC_REQ_READ_ALARM might return a different alarm time than the
  one at the first reset (but the alarm would be disabled).

  If adding the minimum allowed alarm time to the spec, as was discussed in
  the "Open Questions" section of the patch, initializing to the minimum
  allowed alarm time could also become part of the "clean slate", so that
  this exception would be removed.

- The requirements currently allow a "grace period" after disabling through
  VIRTIO_RTC_REQ_SET_ALARM_ENABLED, during which the device could still
  give the alarm notification, or execute custom alarm actions.

  The draft spec permits alarm actions to continue for a short time after
  the alarm has become obsolete, in order to not unnecessarily restrict
  implementations. While I would not consider a sporadic-looking alarm
  notification (which the driver can easily recognize as such) to be a
  problem, the spec does not require to immediately cancel an obsolete
  custom alarm action either.

  But the requirements could be tightened so that all the actions have to
  be completed or canceled before the device marks
  VIRTIO_RTC_REQ_SET_ALARM_ENABLED as used:

      If the driver successfully requests VIRTIO_RTC_REQ_SET_ALARM, or
      VIRTIO_RTC_REQ_SET_ALARM_ENABLED, for clock C, the device MUST stop
      serving any previous alarm expiration event for C before the device
      marks the message as used.

  This would remove the second exception.

I think I will just do the two above changes, if nobody objects.

Thanks for the comment,

Peter

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/