Public bug reported:
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.
** Affects: qemu
Importance: Undecided
Status: New
** Tags: aarch64
--
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:
New
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
