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

[Markus Armbruster <armbru@redhat.com>]

Eric Blake <eblake@redhat.com> writes:

> On 04/12/2017 08:52 AM, Markus Armbruster wrote:
>>>> In other words, these three signals are polite requests to terminate
>>>> QEMU.
>>>>
>>>> Stefan, are there equivalent requests under Windows?  I guess there
>>>> might be one at least for SIGINT, namely whatever happens when you hit
>>>> ^C on the console.
>>>
>>> Mingw has SIGINT (C99 requires it), and that's presumably what happens
>>> for ^C,...
>>>
>>>>
>>>> Could we arrange to run qemu_system_killed() then?
>>>
>>> ...but I don't know why it is not currently wired up to call
>>> qemu_system_killed(), nor do I have enough Windows programming expertise
>>> to try and write such a patch. But I think that is an orthogonal
>>> improvement.  On the other hand, mingw has a definition for SIGTERM (but
>>> I'm not sure how it gets triggered) and no definition at all for SIGHUP
>>> (as evidenced by the #ifdef'fery in the patch to get it to compile under
>>> docker targetting mingw).
>> 
>> If all we need is distingishing host- and guest-initiated shutdown, then
>> detecting the latter reliably lets us stay away from OS-specific stuff.
>> Can we do that?
>
> I'll simplify what I can; I still can't guarantee that mingw will be
> setting the bool correctly in all cases, but setting a bool is easier
> than trying to set a signal name.
>
>>> There are other reasons too: a guest can request shutdown immediately
>>> before the host sends SIGINT. Based on when things are processed, you
>>> could see either the guest or the host as the initiator.  And the race
>>> is not entirely implausible - when trying to shut down a guest, libvirt
>>> first tries to inform the guest to initiate things (whether by interrupt
>>> or guest agent), but after a given amount of time, assumes the guest is
>>> unresponsive and resorts to a signal to qemu. A heavily loaded guest
>>> that takes its time in responding could easily overlap with the timeout
>>> resorting to a host-side action.
>> 
>> This race doesn't worry me.  If both host and guest have initiated a
>> shutdown, then reporting whichever of the two finishes first seems fair.
>
> So maybe I just tone down the docs and not even mention it.

Works for me.

>> Additional ways to terminate QEMU: HMP and QMP command "quit", and the
>> various GUI controls such "close SDL window".
>
> Good points. I have no idea what exit path those take (if they
> raise(SIGINT) internally, it's quite easy - but if they go through some
> other exit path, then I'll need to wire in something else).

Chasing down all host-initiated terminations looks like a fool's errand
to me.  But if we can reliably detect guest-initiated, we don't have to,
do we?