[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Bug 1217339] [PATCH] Unix signal to send ACPI-shutdown

From: Simon
Subject: Re: [Qemu-devel] [Bug 1217339] [PATCH] Unix signal to send ACPI-shutdown to Guest
Date: Wed, 15 Mar 2017 18:46:11 +0100
User-agent: Roundcube Webmail/1.1.2

Daniel P. Berrange:

While I understand your motivation this creates a semantic change for
existing users of QEMU. IOW anyone who is currently relying on use
of SIGHUP will experiance a regression when upgrading QEMU.

So if we want to signal to generate a clean shutdown, we need to pick
one that QEMU hasn't already set a specific behaviour for.

SIGQUIT could be a valid option, or the super generic SIGUSR1


Thanks for your answer Daniel.

OK for not using SIGHUP and keep SIGTERM, SIGINT and SIGHUP to have the
same behavior.

SIGQUIT is reserved for core files generation.

SIGUSR1 is already used in 'util/qemu-progress.c' to trigger a report
on ongoing jobs, so it does not seem usable.

SIGUSR2 is temporarily used in 'util/coroutine-sigaltstack.c' which
takes care however to preserve the original handler. I did not saw
any other place where it is used, so it seems to be a better candidate.

Here is a second version of my patch using SIGUSR2 to cleanly power off
the guest:

Signed-off-by: Simon Geusebroek <address@hidden>
diff -ru qemu-2.8.0/os-posix.c qemu-new/os-posix.c
--- qemu-2.8.0/os-posix.c       2016-12-20 21:16:48.000000000 +0100
+++ qemu-new/os-posix.c 2017-03-15 17:45:28.290737575 +0100
@@ -72,6 +72,7 @@
     sigaction(SIGINT,  &act, NULL);
     sigaction(SIGHUP,  &act, NULL);
     sigaction(SIGTERM, &act, NULL);
+    sigaction(SIGUSR2, &act, NULL);

/* Find a likely location for support files using the location of the binary.
diff -ru qemu-2.8.0/vl.c qemu-new/vl.c
--- qemu-2.8.0/vl.c     2016-12-20 21:16:54.000000000 +0100
+++ qemu-new/vl.c       2017-03-15 17:45:20.866737459 +0100
@@ -1871,7 +1871,11 @@
     /* Cannot call qemu_system_shutdown_request directly because
      * we are in a signal handler.
-    shutdown_requested = 1;
+    if (signal == SIGUSR2) {
+        powerdown_requested = 1;
+    } else {
+        shutdown_requested = 1;
+    }


reply via email to

[Prev in Thread] Current Thread [Next in Thread]