[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] event: Add signal information to SHUTDOWN
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [PATCH] event: Add signal information to SHUTDOWN |
Date: |
Wed, 12 Apr 2017 09:03:54 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
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.
>
> 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).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] event: Add signal information to SHUTDOWN, Paolo Bonzini, 2017/04/13
Re: [Qemu-devel] [PATCH] event: Add signal information to SHUTDOWN, Paolo Bonzini, 2017/04/13