On 2026/09/05 5:57, Vladimir Sementsov-Ogievskiy wrote:
QMP quit, host signals and UI shutdown requests force QEMU to exit
by setting shutdown_action to SHUTDOWN_ACTION_POWEROFF.

This can race with guest shutdown processing. With -no-shutdown,
consider the following sequence:

1. Management sends system_powerdown, then sends SIGTERM after
    waiting for the guest to shut down.
2. QEMU starts processing a guest shutdown request.
3. SIGTERM arrives after qemu_kill_report(), while QEMU is sending
    the guest SHUTDOWN event.
4. The signal handler changes shutdown_action to POWEROFF, so QEMU
    exits instead of pausing.

Management receives SHUTDOWN with guest=true, but QEMU exits despite
-no-shutdown, without reporting a host SHUTDOWN event or printing
the signal diagnostic.

Store forced and regular shutdown requests separately, and decide
whether to exit based on the request being processed. Leave
shutdown_action under user control. A forced request arriving while
a regular request is being processed remains pending for the next
main loop iteration.

Keep qemu_shutdown_requested() checking both kinds of requests for
its Xen caller.

There is no need to clear shutdown_force_requested with qatomic_xchg():
processing a forced shutdown request always exits the main loop.

Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]>

Reviewed-by: Akihiko Odaki <[email protected]>

Regards,
Akihiko Odaki

Reply via email to