From: Eric Blake <eblake@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org,
Stefano Stabellini <sstabellini@kernel.org>,
Eduardo Habkost <ehabkost@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Juan Quintela <quintela@redhat.com>,
alistair.francis@xilinx.com,
zhanghailiang <zhang.zhanghailiang@huawei.com>,
"open list:X86" <xen-devel@lists.xenproject.org>,
Anthony Perard <anthony.perard@citrix.com>,
Paolo Bonzini <pbonzini@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v6 2/5] shutdown: Prepare for use of an enum in reset/shutdown_request
Date: Mon, 8 May 2017 13:33:41 -0500 [thread overview]
Message-ID: <b5139e70-1be8-49ae-282b-ceac5867f4bb@redhat.com> (raw)
In-Reply-To: <87zien433w.fsf@dusky.pond.sub.org>
[-- Attachment #1: Type: text/plain, Size: 6409 bytes --]
On 05/08/2017 01:26 PM, Markus Armbruster wrote:
> Eric Blake <eblake@redhat.com> writes:
>
>> We want to track why a guest was shutdown; in particular, being able
>> to tell the difference between a guest request (such as ACPI request)
>> and host request (such as SIGINT) will prove useful to libvirt.
>> Since all requests eventually end up changing shutdown_requested in
>> vl.c, the logical change is to make that value track the reason,
>> rather than its current 0/1 contents.
>>
>> Since command-line options control whether a reset request is turned
>> into a shutdown request instead, the same treatment is given to
>> reset_requested.
>>
>> This patch adds an internal enum ShutdownCause that describes reasons
>> that a shutdown can be requested, and changes qemu_system_reset() to
>> pass the reason through, although for now it is not reported. The
>> enum could be exported via QAPI at a later date, if deemed necessary,
>> but for now, there has not been a request to expose that much detail
>> to end clients.
>>
>> For now, we only populate the reason with HOST_ERROR, along with FIXME
>> comments that describe our plans for how to pass an actual correct
>> reason.
>
> In other words, replacing 0 by SHUTDOWN_CAUSE_NONE, and 1 by
> SHUTDOWN_CAUSE_HOST_ERROR. Makes sense.
Maybe I could have ordered HOST_ERROR to actually be 1...
>> +/* Enumeration of various causes for shutdown. */
>> +typedef enum ShutdownCause ShutdownCause;
>> +enum ShutdownCause {
>
> Why define the typedef separately here? What's wrong with
>
> typedef enum ShutdownCause {
> ...
> } ShutdownCause;
>
> ?
That would work too. I don't know if the code base has a strong
preference for one form over the other.
>
>> + SHUTDOWN_CAUSE_NONE, /* No shutdown requested yet */
>
> Comment is fine. Possible alternative: /* No shutdown request pending */
>
>> + SHUTDOWN_CAUSE_HOST_QMP, /* Reaction to a QMP command, like 'quit' */
>> + SHUTDOWN_CAUSE_HOST_SIGNAL, /* Reaction to a signal, such as SIGINT */
>> + SHUTDOWN_CAUSE_HOST_UI, /* Reaction to UI event, like window close */
>> + SHUTDOWN_CAUSE_HOST_ERROR, /* An error prevents further use of guest */
...rather than 4. I don't know that it matters much.
>> -static int qemu_reset_requested(void)
>> +static ShutdownCause qemu_reset_requested(void)
>> {
>> - int r = reset_requested;
>> + ShutdownCause r = reset_requested;
>
> Good opportunity to insert a blank line here.
>
Sure.
>> if (r && replay_checkpoint(CHECKPOINT_RESET_REQUESTED)) {
>> - reset_requested = 0;
>> + reset_requested = SHUTDOWN_CAUSE_NONE;
>> return r;
>> }
>> - return false;
>> + return SHUTDOWN_CAUSE_NONE;
>> }
>>
>> static int qemu_suspend_requested(void)
>> @@ -1686,7 +1687,12 @@ static int qemu_debug_requested(void)
>> return r;
>> }
>>
>> -void qemu_system_reset(bool report)
>> +/*
>> + * Reset the VM. If @report is VMRESET_REPORT, issue an event, using
>> + * the @reason interpreted as ShutdownCause for details. Otherwise,
>> + * @report is VMRESET_SILENT and @reason is ignored.
>> + */
>
> "interpreted as ShutdownCause"? It *is* a ShutdownCause. Leftover?
Oh, yeah. In v5, the parameter was 'int'.
>
>> +void qemu_system_reset(bool report, ShutdownCause reason)
>> {
>> MachineClass *mc;
>>
>> @@ -1700,6 +1706,7 @@ void qemu_system_reset(bool report)
>> qemu_devices_reset();
>> }
>> if (report) {
>> + assert(reason);
>> qapi_event_send_reset(&error_abort);
>> }
>> cpu_synchronize_all_post_reset();
>
> Looks like we're not using @reason "for details" just yet.
Correct. I can add a FIXME (to be removed in the later patch where it is
used) if that is desired.
>> @@ -1807,7 +1815,7 @@ void qemu_system_killed(int signal, pid_t pid)
>> /* Cannot call qemu_system_shutdown_request directly because
>> * we are in a signal handler.
>> */
>> - shutdown_requested = 1;
>> + shutdown_requested = SHUTDOWN_CAUSE_HOST_SIGNAL;
>
> Should this be SHUTDOWN_CAUSE_HOST_ERROR, to be updated in the next
> patch? Alternatively, tweak this patch's commit message?
This is the one case that we actually do have a strong cause affiliated
with the reason without having to resort to changing function
signatures. Commit message tweak is better.
>> @@ -1846,13 +1855,16 @@ void qemu_system_debug_request(void)
>> static bool main_loop_should_exit(void)
>> {
>> RunState r;
>> + ShutdownCause request;
>> +
>> if (qemu_debug_requested()) {
>> vm_stop(RUN_STATE_DEBUG);
>> }
>> if (qemu_suspend_requested()) {
>> qemu_system_suspend();
>> }
>> - if (qemu_shutdown_requested()) {
>> + request = qemu_shutdown_requested();
>> + if (request) {
>> qemu_kill_report();
>> qapi_event_send_shutdown(&error_abort);
>> if (no_shutdown) {
>
> The detour through @request appears isn't necessary here. Perhaps you
> do it for consistency with the next hunk. Do you? Just asking to make
> sure I get what you're doing.
Consistency with the next hunk, AND because a later patch then uses
'request' to pass an additional parameter to qapi_event_send_shutdown().
>
> Hmm, there's another one in xen-hvm.c, but consistency hardly applies
> there. If later patches add more uses, you might want delay the change
> until then.
Can do, if it makes incremental reviews easier.
>> +++ b/migration/savevm.c
>> @@ -2300,7 +2300,7 @@ int load_vmstate(const char *name)
>> return -EINVAL;
>> }
>>
>> - qemu_system_reset(VMRESET_SILENT);
>> + qemu_system_reset(VMRESET_SILENT, SHUTDOWN_CAUSE_NONE);
>> mis->from_src_file = f;
>>
>> aio_context_acquire(aio_context);
>
> You seem to be passing SHUTDOWN_CAUSE_NONE exactly with VMRESET_SILENT.
> Would it be possible to have SHUTDOWN_CAUSE_NONE imply !report, any
> other case imply report, and get rid of the first parameter?
Indeed, and it would also get rid of the ugly
#define VMRESET_SILENT false
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2017-05-08 18:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-05 19:38 [Qemu-devel] [PATCH v6 0/5] event: Add source information to SHUTDOWN Eric Blake
2017-05-05 19:38 ` [Qemu-devel] [PATCH v6 1/5] shutdown: Simplify shutdown_signal Eric Blake
2017-05-05 23:41 ` Alistair Francis
2017-05-05 19:38 ` [Qemu-devel] [PATCH v6 2/5] shutdown: Prepare for use of an enum in reset/shutdown_request Eric Blake
2017-05-08 18:26 ` Markus Armbruster
2017-05-08 18:33 ` Eric Blake [this message]
2017-05-09 11:30 ` Markus Armbruster
2017-05-05 19:38 ` [Qemu-devel] [PATCH v6 3/5] shutdown: Add source information to SHUTDOWN and RESET Eric Blake
2017-05-08 5:26 ` David Gibson
2017-05-08 14:32 ` Eric Blake
2017-05-10 7:33 ` David Gibson
2017-05-05 19:38 ` [Qemu-devel] [PATCH v6 4/5] shutdown: Preserve shutdown cause through replay Eric Blake
2017-05-05 19:38 ` [Qemu-devel] [PATCH v6 5/5] shutdown: Expose bool cause in SHUTDOWN and RESET events Eric Blake
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=b5139e70-1be8-49ae-282b-ceac5867f4bb@redhat.com \
--to=eblake@redhat.com \
--cc=alistair.francis@xilinx.com \
--cc=anthony.perard@citrix.com \
--cc=armbru@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=rth@twiddle.net \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
--cc=zhang.zhanghailiang@huawei.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).