[Qemu-devel] [Bug 1818207] Re: [aarch64] VM status remains "running" after it's suspended

[Laszlo Ersek \(Red Hat\)]

In order for the guest kernel to expose ACPI S3 suspend to a privileged
guest user, the guest kernel first checks if the platform (hardware and
firmware) support ACPI S3. This in turn depends on whether the DSDT
offers a package called _S3.

For example, on the "pc" machine type, S3 can be disabled on the QEMU
command line with "-global PIIX4_PM.disable_s3=1". On the "q35" machine
type, the same is achievable with "-global ICH9-LPC.disable_s3=1". One
thing both of these switches do is that they hide the _S3 package in the
DSDT from the guest OS (they prevent the generation of the _S3 package
in the DSDT).

On the "virt" machine type, the "_S3" package is not generated at all,
in the DSDT. For this reason, ACPI S3 is never valid for the guest
kernel to expose.

Now let's look at the kernel docs:

https://www.kernel.org/doc/html/v4.18/admin-guide/pm/sleep-states.html
#suspend-to-ram

> On ACPI-based systems [Suspend-to-RAM] is mapped to the S3 system
> state defined by ACPI.

However, when you write "mem" to "/sys/power/state", the guest kernel is
not required to Suspend-to-RAM (and hence enter ACPI S3):

https://www.kernel.org/doc/html/v4.18/admin-guide/pm/sleep-states.html
#basic-sysfs-interfaces-for-system-suspend-and-hibernation

> The string "mem" is interpreted in accordance with the contents of the
> mem_sleep file described below

> The strings that may be present in [mem_sleep] are "s2idle", "shallow"
> and "deep". The string "s2idle" always represents suspend-to-idle and,
> by convention, "shallow" and "deep" represent standby and
> suspend-to-RAM, respectively.

This is what I get:

> # uname -r
> 4.14.0-115.2.2.el7a.aarch64
>
> # cat /sys/power/state
> freeze mem disk
>
> # cat /sys/power/mem_sleep
> [s2idle]

Therefore, when you write "mem" to "/sys/power/state", the guest kernel
picks "s2idle" (suspend-to-idle,
<https://www.kernel.org/doc/html/v4.18/admin-guide/pm/sleep-states.html#s2idle>):

> This is a generic, pure software, light-weight variant of system
> suspend (also referred to as S2I or S2Idle). [...] by freezing user
> space, suspending the timekeeping and putting all I/O devices into
> low-power states [...] This state can be used on platforms without
> support for standby or suspend-to-RAM [...]

And that's why the "info status" HMP command reports "VM status:
running".

(Side comment: the ArmVirtQemu firmware from edk2 doesn't support ACPI
S3 either.)


** Changed in: qemu
       Status: New => Invalid

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1818207

Title:
  [aarch64] VM status remains "running" after it's suspended

Status in QEMU:
  Invalid

Bug description:
  The issue is observed on aarch64 (I didn't check x86) with latest
  upstream QEMU bits.

  Steps to reproduce:

  1) start guest

  2) suspend guest with this command:

  # echo mem > /sys/power/state

    Check console messages, which should indicate that guest has been
  suspended.

  3) check guest status through HMP command "info status":

    (qemu) info status
     info status
     VM status: running

  Note it's "running", which is incorrect.

  QEMU version:

  # qemu-system-aarch64 --version
  QEMU emulator version 3.1.50 (v3.1.0-2203-g9403bcc)
  Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers

  The issue prevents user from resuming a suspended guest through
  "system_wakeup" HMP command, because QEMU thinks the guest is in
  running state and does nothing.

  I think the issues occurs because qemu_system_wakeup_request() doesn't
  get called. It seems the root cause is with ACPI related code.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1818207/+subscriptions