From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-devel@nongnu.org, armbru@redhat.com, berrange@redhat.com,
alistair.francis@xilinx.com,
Stefano Stabellini <sstabellini@kernel.org>,
Anthony Perard <anthony.perard@citrix.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>,
Eduardo Habkost <ehabkost@redhat.com>,
zhanghailiang <zhang.zhanghailiang@huawei.com>,
Juan Quintela <quintela@redhat.com>,
"open list:X86" <xen-devel@lists.xenproject.org>
Subject: Re: [Qemu-devel] [PATCH v5 2/4] shutdown: Prepare for use of an enum in reset/shutdown_request
Date: Fri, 28 Apr 2017 17:09:01 +0100 [thread overview]
Message-ID: <20170428160901.GK2085@work-vm> (raw)
In-Reply-To: <550a4e37-c4b3-181d-876c-64d73e96e78c@redhat.com>
* Eric Blake (eblake@redhat.com) wrote:
> On 04/28/2017 10:27 AM, Dr. David Alan Gilbert wrote:
>
> >>>> +# Enumeration of various causes for shutdown.
> >>>> +#
> >>>> +# @host-qmp: Reaction to a QMP command, such as 'quit'
> >>>> +# @host-signal: Reaction to a signal, such as SIGINT
> >>>> +# @host-ui: Reaction to a UI event, such as closing the window
> >>>> +# @host-replay: The host is replaying an earlier shutdown event
> >>>> +# @host-error: Qemu encountered an error that prevents further use of the guest
> >>>> +# @guest-shutdown: The guest requested a shutdown, such as via ACPI or
> >>>> +# other hardware-specific action
> >>>> +# @guest-reset: The guest requested a reset, and the command line
> >>>> +# response to a reset is to instead trigger a shutdown
> >>>> +# @guest-panic: The guest panicked, and the command line response to
> >>>> +# a panic is to trigger a shutdown
> >>>
>
> > At a higher level, using your tags, I'm not sure where a reset triggered
> > by a fault detected by the hypervisor lives - e.g. an x86 triple fault
> > where the guest screws up so badly that it just gets reset. Is
> > that a guest-reset or a guest-panic or what - neither case
> > was actually asked for by the guest itself.
>
> Wouldn't that be host-error (qemu detected an error that prevents
> further execution of the guest without a reset - and a triple fault
> seems to fall into the category of the guest getting itself wedged
> rather than actually trying to reset)? Except patch 3 only used
> SHUTDOWN_TYPE_HOST_ERROR in the xen portion of the patch.
>
> So if any x86 expert has an opinion on where triple-fault handling is
> emulated, and what category should be used there, I'm welcome to
> tweaking this series.
It's pretty much on the border anyway, I don't think it matters too
much; it sounds perfectly reasonable.
Dave
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc. +1-919-301-3266
> Virtualization: qemu.org | libvirt.org
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
WARNING: multiple messages have this Message-ID (diff)
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
berrange@redhat.com, Eduardo Habkost <ehabkost@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
armbru@redhat.com, Juan Quintela <quintela@redhat.com>,
qemu-devel@nongnu.org, 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>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH v5 2/4] shutdown: Prepare for use of an enum in reset/shutdown_request
Date: Fri, 28 Apr 2017 17:09:01 +0100 [thread overview]
Message-ID: <20170428160901.GK2085@work-vm> (raw)
In-Reply-To: <550a4e37-c4b3-181d-876c-64d73e96e78c@redhat.com>
* Eric Blake (eblake@redhat.com) wrote:
> On 04/28/2017 10:27 AM, Dr. David Alan Gilbert wrote:
>
> >>>> +# Enumeration of various causes for shutdown.
> >>>> +#
> >>>> +# @host-qmp: Reaction to a QMP command, such as 'quit'
> >>>> +# @host-signal: Reaction to a signal, such as SIGINT
> >>>> +# @host-ui: Reaction to a UI event, such as closing the window
> >>>> +# @host-replay: The host is replaying an earlier shutdown event
> >>>> +# @host-error: Qemu encountered an error that prevents further use of the guest
> >>>> +# @guest-shutdown: The guest requested a shutdown, such as via ACPI or
> >>>> +# other hardware-specific action
> >>>> +# @guest-reset: The guest requested a reset, and the command line
> >>>> +# response to a reset is to instead trigger a shutdown
> >>>> +# @guest-panic: The guest panicked, and the command line response to
> >>>> +# a panic is to trigger a shutdown
> >>>
>
> > At a higher level, using your tags, I'm not sure where a reset triggered
> > by a fault detected by the hypervisor lives - e.g. an x86 triple fault
> > where the guest screws up so badly that it just gets reset. Is
> > that a guest-reset or a guest-panic or what - neither case
> > was actually asked for by the guest itself.
>
> Wouldn't that be host-error (qemu detected an error that prevents
> further execution of the guest without a reset - and a triple fault
> seems to fall into the category of the guest getting itself wedged
> rather than actually trying to reset)? Except patch 3 only used
> SHUTDOWN_TYPE_HOST_ERROR in the xen portion of the patch.
>
> So if any x86 expert has an opinion on where triple-fault handling is
> emulated, and what category should be used there, I'm welcome to
> tweaking this series.
It's pretty much on the border anyway, I don't think it matters too
much; it sounds perfectly reasonable.
Dave
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc. +1-919-301-3266
> Virtualization: qemu.org | libvirt.org
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-04-28 16:09 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-28 2:13 [Qemu-devel] [PATCH v5 0/4] event: Add source information to SHUTDOWN Eric Blake
2017-04-28 2:13 ` [Qemu-devel] [PATCH v5 1/4] shutdown: Simplify shutdown_signal Eric Blake
2017-04-28 14:42 ` Markus Armbruster
2017-04-28 2:13 ` [Qemu-devel] [PATCH v5 2/4] shutdown: Prepare for use of an enum in reset/shutdown_request Eric Blake
2017-04-28 2:13 ` Eric Blake
2017-04-28 8:08 ` [Qemu-devel] " Dr. David Alan Gilbert
2017-04-28 8:08 ` Dr. David Alan Gilbert
2017-04-28 14:35 ` [Qemu-devel] " Eric Blake
2017-04-28 14:35 ` Eric Blake
2017-04-28 15:27 ` [Qemu-devel] " Dr. David Alan Gilbert
2017-04-28 15:27 ` Dr. David Alan Gilbert
2017-04-28 15:57 ` [Qemu-devel] " Eric Blake
2017-04-28 15:57 ` Eric Blake
2017-04-28 16:09 ` Dr. David Alan Gilbert [this message]
2017-04-28 16:09 ` Dr. David Alan Gilbert
2017-04-28 18:05 ` [Qemu-devel] " Eric Blake
2017-04-28 18:05 ` Eric Blake
2017-04-28 18:13 ` [Qemu-devel] " Dr. David Alan Gilbert
2017-04-28 18:13 ` Dr. David Alan Gilbert
2017-04-28 14:45 ` [Qemu-devel] " Markus Armbruster
2017-04-28 14:45 ` Markus Armbruster
2017-04-28 14:42 ` Markus Armbruster
2017-04-28 14:42 ` Markus Armbruster
2017-04-28 22:34 ` Eric Blake
2017-04-28 22:34 ` Eric Blake
2017-05-02 11:47 ` Markus Armbruster
2017-05-02 11:47 ` Markus Armbruster
2017-04-28 2:13 ` [PATCH v5 3/4] shutdown: Add source information to SHUTDOWN and RESET Eric Blake
2017-04-28 2:13 ` [Qemu-devel] " Eric Blake
2017-04-28 2:13 ` Eric Blake
2017-04-28 15:01 ` [Qemu-devel] " Markus Armbruster
2017-04-28 15:01 ` Markus Armbruster
2017-04-28 15:01 ` Markus Armbruster
2017-04-28 15:01 ` Markus Armbruster
2017-04-28 22:44 ` [Qemu-devel] replay help [was: [PATCH v5 3/4] shutdown: Add source information to SHUTDOWN and RESET] Eric Blake
2017-05-02 10:54 ` Pavel Dovgalyuk
2017-05-02 8:13 ` [Qemu-devel] [PATCH v5 3/4] shutdown: Add source information to SHUTDOWN and RESET Pavel Dovgalyuk
2017-05-02 8:13 ` Pavel Dovgalyuk
2017-05-02 8:13 ` Pavel Dovgalyuk
2017-05-02 8:13 ` Pavel Dovgalyuk
2017-05-01 3:58 ` David Gibson
2017-05-01 3:58 ` [Qemu-devel] " David Gibson
2017-05-01 3:58 ` David Gibson
2017-05-01 3:58 ` David Gibson
2017-05-05 8:36 ` [Qemu-devel] " Mark Cave-Ayland
2017-04-28 2:13 ` Eric Blake
2017-04-28 2:13 ` [Qemu-devel] [PATCH v5 4/4] RFC: shutdown: Expose full ShutdownCause across QMP Eric Blake
2017-04-28 22:48 ` 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=20170428160901.GK2085@work-vm \
--to=dgilbert@redhat.com \
--cc=alistair.francis@xilinx.com \
--cc=anthony.perard@citrix.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=eblake@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 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.