Re: [Qemu-devel] [PATCH v5 2/4] shutdown: Prepare for use of an enum in reset/shutdown_request

[Eric Blake]

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.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature