Re: [virtio-comment] [RFC] Define a low power state for devices

[David Stevens <stevensd@chromium.org>]

On Fri, Apr 7, 2023 at 8:27âPM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Thu, Apr 06, 2023 at 04:30:02PM +0900, David Stevens wrote:
> > This RFC defines a low power state for virtio devices, to gives
> > drivers an option for power management besides simply resetting their
> > device.
> >
> > This patch is a draft aimed at starting a discussion, rather than being
> > a finalized patch.
> >
> > To provide some context on where this is coming from, I'm working on
> > reducing the power overhead of ARCVM (virtualized Android running on
> > ChromeOS). One of the big gaps in ARCVM power management is that it does
> > not implement Android's partial wake locks - i.e. the (virtualized) CPUs
> > are always on, even if the (virtualized) screen is off. This means we
> > can't force apps to stop running when they shouldn't be running, which
> > can lead to higher power consumption compared to the ChromeOS baseline.
> >
> > Partial wake locks are built on s2idle, but unfortunately the current
> > power management of virtio drivers does not let us use s2idle. The fact
> > that power management is based around resetting the virtio device means
> > that it doesn't work with stateful devices (e.g. virtio-fs). Even for
> > stateless devices, re-initializing all of the devices takes longer than
> > we would like, especially on lower end hardware.
> >
> > My rough idea for how to address this would be to make the existing
> > virtio power management targeted at S4 specifically (i.e. the freeze
> > device callback). For S0/S1/S3 (i.e. the suspend device callback), this
> > new lighter weight low power state would be used if available -
> > otherwise it would fall back to the existing S4 power management code.
> >
> > I have a very rough prototype that seems to work, and I haven't seen
> > anything that makes me think this approach is fundamentally unworkable.
> > That said, I would like to get feedback on the approach earlier rather
> > than later.
> > ---
> >  content.tex | 26 ++++++++++++++++++++++++++
> >  1 file changed, 26 insertions(+)
> >
> > diff --git a/content.tex b/content.tex
> > index cff548ab9675..01da6f62ef20 100644
> > --- a/content.tex
> > +++ b/content.tex
> > @@ -449,6 +449,28 @@ \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}
> > +
> > +A virtio device can be put into a low power state when the
> > +VIRTIO_F_LOW_POWER bit is negotiated. How a driver puts a
> > +device into a low power state is transport specific.
> > +
> > +In general, a virtio device in a low power state should
> > +avoid initating any communication with the driver. However,
> > +certain device-specific functionality is exempt from this
> > +requirement. Such functionality is detailed in the device
> > +type specifications.
> > +
> > +% One example of such functionality would be allowing
> > +% the virtio-net device to wake up the guest to deliver
> > +% incoming network packets.
> > +
> > +While a virtio device is in a low power state, it should
> > +maintain any type specific state in such a way that it is
> > +able to immediately resume functioning upon leaving the low
> > +power state, without the need for any additional
> > +communication with the driver.
> > +
> >  \chapter{General Initialization And Device Operation}\label{sec:General Initialization And Device Operation}
> >
> >  We start with an overview of device initialization, then expand on the
> > @@ -803,6 +825,10 @@ \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
> >    that the driver can reset a queue individually.
> >    See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}.
> >
> > +  \item[VIRTIO_F_LOW_POWER(41)] This feature indicates
> > +  that the driver can put the device into a low power mode.
> > +  See \ref{sec:Basic Facilities of a Virtio Device / Low Power Mode}.
> > +
> >  \end{description}
> >
> >  \drivernormative{\section}{Reserved Feature Bits}{Reserved Feature Bits}
>
> So what purpose does this flag serve exactly?  I guess transports also
> provide ways to enumerate supported power states, no?

This is mostly here to parallel the VIRTIO_F_SR_IOV feature flag.
Generally speaking, it does seem redundant with the transport-specific
enumeration.

The two potential uses I can think of would be to allow devices to
support transport level power management without supporting virtio
level power management (might apply to existing devices?) and to allow
devices to behave differently if they know that the driver doesn't
support virtio power management. But I don't know how useful these are
in practice.

-David