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
