On Wed, Mar 15, 2017 at 06:45:57PM +0000, Peter Maydell wrote: > On 15 March 2017 at 18:08, Daniel P. Berrange <berra...@redhat.com> wrote: > > On Wed, Mar 15, 2017 at 06:00:40PM +0000, Peter Maydell wrote: > >> On 15 March 2017 at 17:46, Simon <qemu.b...@whitewinterwolf.com> wrote: > >> > 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. > >> > >> I don't think we can use SIGUSR2 here -- as you say, it's used > >> in the sigaltstack version of coroutines, and so there would > >> be races if the user tried to use SIGUSR2 to power down the > >> machine while we happened to be starting a new coroutine. > >> > >> SIGUSR1 is also no good, as it is used by main-loop.c as > >> the SIG_IPI. > > > > Which means we'd be into the realm of having to pick SIGRTMIN + N for > > some arbitrary N >= 0 > > That's pretty nasty. Why can't we use SIGHUP, again?
Because QEMU already designate that as doing an immediate stop - ie it'll allow QEMU block layer to flush pending I/O, but it will not wait for the guest to shutdown. If we change that behaviour we'll break anyone who is already relying on SIGHUP - qemu might never exit at all if the guest ignores the ACPI request Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|