All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominik Csapak <d.csapak@proxmox.com>
To: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Cc: armbru@redhat.com, eblake@redhat.com
Subject: Re: [Qemu-devel] [PATCH] qapi: add info about reset to SHUTDOWN event
Date: Wed, 17 Oct 2018 13:34:01 +0200	[thread overview]
Message-ID: <d5d914fc-daa1-4164-44ba-a02365a44ddb@proxmox.com> (raw)
In-Reply-To: <d2f89cb6-0ea5-75bc-1bb1-3f0ce6509ec4@redhat.com>

On 10/17/18 12:58 PM, Paolo Bonzini wrote:
> On 17/10/2018 09:17, Dominik Csapak wrote:
>> On 10/8/18 3:19 PM, Dominik Csapak wrote:
>>> when '-no-reboot' is set, it is interesting if the guest was originally
>>> shutdown or reset, so save and return that info
>>
>>
>>    {
>>        if (no_reboot && reason != SHUTDOWN_CAUSE_SUBSYSTEM_RESET) {
>> +        shutdown_was_reset = true;
>>            shutdown_requested = reason;
>>        } else {
>>            reset_requested = reason;
>> @@ -1807,7 +1809,8 @@ static bool main_loop_should_exit(void)
>>        request = qemu_shutdown_requested();
>>        if (request) {
>>            qemu_kill_report();
>> -        qapi_event_send_shutdown(shutdown_caused_by_guest(request));
>> +        qapi_event_send_shutdown(shutdown_caused_by_guest(request),
>> +                                 shutdown_was_reset);
> 
> So the problem with shutdown_caused_by_guest is that you get the same
> value for both guest reset and guest shutdown.  Could we instead just
> pass the ShutdownCause in the event (similar to what was proposed even
> when discussing commit 08fba7ac9b618516a5f1d096f78a7e2837fe0594)?
> 
> You would get either guest-reset or host-qmp if it's a reset; the same
> host-qmp reason could account for both "quit" and "system_reset", but in
> practice the caller will know if it has asked for a hard shutdown or a
> reset.

i would find it nicer to always be able to distinguish between
a reset and a normal exit, since it would be less work on the
management side (i.e. we would have to handle the qmp reset elsewhere
instead of in the same process that monitors the events)

also it would make the 'guest' parameter redundant or change the api and 
i am not sure about how stable it has to be?

  reply	other threads:[~2018-10-17 11:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-08 13:19 [Qemu-devel] [PATCH] qapi: add info about reset to SHUTDOWN event Dominik Csapak
2018-10-17  7:17 ` Dominik Csapak
2018-10-17 10:58   ` Paolo Bonzini
2018-10-17 11:34     ` Dominik Csapak [this message]
2018-10-17 11:36       ` Paolo Bonzini
2018-10-17 13:54     ` Eric Blake
2018-10-17 14:43       ` Paolo Bonzini
2018-10-23  7:51         ` Dominik Csapak
2018-10-17 13:51   ` Eric Blake
2018-10-17 14:02     ` Dominik Csapak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d5d914fc-daa1-4164-44ba-a02365a44ddb@proxmox.com \
    --to=d.csapak@proxmox.com \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.