Re: [virtio-comment] [PATCH v2 1/1] Define a low power mode for devices

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Nov 13, 2023 at 03:19:50PM +0900, David Stevens wrote:
> Define a low power mode for virtio devices where the devices are
> expected to maintain their state. This gives drivers an option for power
> management besides simply resetting their device. In the virtualization
> use case, this allows the guest to be suspended even with stateful
> virtio devices like gpu and fs.
> 
> Low power mode is primarily defined at the transport layer. The only
> part that depends on device-type specific details is whether a given
> virtqueue is device driven or driver driven.
> 
> This change only defines the transport-specific implementation for
> Virtio over PCI.
> ---
>  content.tex       | 45 +++++++++++++++++++++++++++++++++++++++++++++
>  transport-pci.tex |  7 +++++++
>  2 files changed, 52 insertions(+)
> 
> diff --git a/content.tex b/content.tex
> index 0a62dce5f65f..7016778c38d6 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -502,6 +502,51 @@ \section{Exporting Objects}\label{sec:Basic Facilities of a Virtio Device / Expo
>  types. It is RECOMMENDED that devices generate version 4
>  UUIDs as specified by \hyperref[intro:rfc4122]{[RFC4122]}.
>  
> +\section{Low Power Mode}\label{sec:Basic Facilities of a Virtio Device / Low Power Mode}




> +
> +Low power mode is a state a driver can put its device into to try to
> +reduce the resource consumption of the device.

This sounds somewhat vague and the grammar is convoluted. E.g. who
tries what?

How about something like:
	Devices and drivers can implement a low power mode: in this mode device
	state is maintained but driver does not access the device, allowing the
	device to reduce the power consumption.


> While in low power
> +mode, a device can generate wakeup events to inform its driver about
> +device driven events.

using the term events here is confusing because it already
has a meaning in the spec solely related to ring (discussed
in the context of device event suppression).
And "driven" is too close to "driver" and
confuses me.

I think these are
really vq notifications and config change events right?
Maybe just say so instead of coming up with new terms.


> How a device is put into and taken out of low
> +power mode is transport specific, as is how wakeup events are
> +implemented.
> +

I would move the definition of device driven queues here and
add the definition of driver driven queues.

And add a high level explanation of how device and driver
interact (repeating a bit what normative sections say,
this duplication is normal).


> +\devicenormative{\subsection}{Low Power Mode}{Basic Facilities of a Virtio
> +Device / Low Power Mode}
> +
> +A device in low power mode MUST maintain its state such that all
> +driver visible state after exiting low power mode exactly matches
> +driver visible state before entering low power mode.
> +
> +A device in low power mode MUST continue to operate device driven
> +queues. Device driven queues are queues where the driver provides

makes available is the term we use

> +buffers to the device that the device holds onto for an indeterminate
> +time until some device-side event occurs (e.g. event queues, rx
> +queues). When sending a used buffer notification for such a queue, the
> +device MUST generate a wakeup event.

is it only when sending notification? not when buffers are used?
also what does "when" mean here? after sending a notification?

> +
> +A device in low power mode MUST continue to send configuration change
> +notifications. When sending a configuration change notification, the
> +device MUST generate a wakeup event.
> +
> +A device in low power mode SHOULD NOT generate wakeup events for
> +driver driven queues. A device SHOULD stop sending used buffer
> +notifications for such queues until after exiting the low power state.
> +
> +A device in low power mode SHOULD minimize its resource usage,
> +although what steps to take are specific to a particular device
> +implementation.
> +
> +\drivernormative{\subsection}{Low Power Mode}{Basic Facilities of a Virtio
> +Device / Low Power Mode}
> +
> +A driver MUST not interact with a device in low power mode except
> +to take the device out of low power mode

i get this
in a transport specific manner, yes?

> or to handle wakeup events
> +generated by the device.

i don't get this. what does "handle" mean here?


> +
> +A driver MAY use wakeup events as a trigger to take the device out of
> +low power mode, but it MAY also ignore wakeup events.
> +
>  \input{admin.tex}
>  
>  \chapter{General Initialization And Device Operation}\label{sec:General Initialization And Device Operation}
> diff --git a/transport-pci.tex b/transport-pci.tex
> index a5c6719ea871..6694e0f72d46 100644
> --- a/transport-pci.tex
> +++ b/transport-pci.tex
> @@ -1212,3 +1212,10 @@ \subsubsection{Driver Handling Interrupts}\label{sec:Virtio Transport Options /
>          re-examine the configuration space to see what changed.
>      \end{itemize}
>  \end{itemize}
> +
> +\subsubsection{Low Power Mode}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Low Power Mode}
> +

a bit of introduction here can't hurt too - this is a cmpletely separate
section.
e.g. devices can implement support for low power mode, see
(link to generic description).

> +Low power mode corresponds to the device power management state
> +D3\textsubscript{Hot}. A device advertises support for low power mode
> +by presenting the PCI Power Management Capability. Wakeup events are
> +implemented as PCI Power Management Events (PMEs).
> -- 
> 2.42.0.869.gea05f2083d-goog
> 
> 
> 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/
> 


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/