[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] [RFC] Define a low power state for devices
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? -- MST
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]