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

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]

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(+)

I'm curious to see how this maps to virtio-pci and the underlying PCI
power management features. Do you have a VIRTIO PCI transport spec
proposal you can share?

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]