Re: [Qemu-devel] [PATCH] event: Add signal information to SHUTDOWN

[Eric Blake]

On 04/07/2017 04:35 AM, Daniel P. Berrange wrote:
> On Thu, Apr 06, 2017 at 04:09:17PM -0500, Eric Blake wrote:
>> qemu_kill_report() is already able to tell whether a shutdown
>> was triggered by guest action (no output) or by a host signal
>> (a message about termination is printed via error_report); but
>> this information is then lost.  Libvirt would like to be able
>> to distinguish between a SHUTDOWN event triggered solely by
>> guest request and one triggered by a SIGTERM on the host.
>>
>> Enhance the SHUTDOWN event to pass the value of shutdown_signal
>> through to the monitor client, suitably remapped into a
>> platform-neutral string.  Note that mingw lacks decent signal
>> support, and will never report a signal because it never calls
>> qemu_system_killed().
> 
> Is it conceivable that we find a non-signal based way to distinguish
> guest initiated shutdown, from host OS initiated kill when on Win32 ?
> 
> If so, rather than including a 'signal' field in the event, it might
> be better to just have a 'source': 'host|guest' field. ie we would
> indicate /who/ initiated the shutdown, rather than /how/ it was
> initiated.
> 
> Or perhaps we should include both the who & the how ?

It's always something that can be extended later (possibly by even
adding an 'unknown' to the how, if there is no real signal name for
mingw).  The 'who' is kind of implied by the presence or absence of the
optional 'how', and even though mingw doesn't have SIGHUP, it DOES have
SIGINT (C requires that), so it is still probably that someone
interested enough could wire up Ctrl-C on mingw host to trigger 'int' as
the 'how', rather than the current situation of Ctrl-C presumably doing
nothing and 'how' never being reported.  (I haven't ever actually tried
to run a guest with mingw as the host, to know if Ctrl-C even works...)

>> @@ -1852,8 +1867,8 @@ static bool main_loop_should_exit(void)
>>          qemu_system_suspend();
>>      }
>>      if (qemu_shutdown_requested()) {
>> -        qemu_kill_report();
>> -        qapi_event_send_shutdown(&error_abort);
>> +        ShutdownSignal ss = qemu_kill_report();
>> +        qapi_event_send_shutdown(ss < SHUTDOWN_SIGNAL__MAX, ss, 
>> &error_abort);
>>          if (no_shutdown) {
>>              vm_stop(RUN_STATE_SHUTDOWN);
>>          } else {
> 
> If any to the above question means we keep '*signal', then consider this
> 
> Reviewed-by: Daniel P. Berrange <address@hidden>
> 

I still think for Unix-y hosts that '*signal' is useful (some people DO
care whether it was SIGTERM vs. SIGHUP that caused qemu to shutdown,
especially if the two signals are sent by two different agents and can
therefore let the management distinguish which agent asked for the guest
to be killed).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature