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

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2594 bytes --]

On 04/28/2017 03:08 AM, Dr. David Alan Gilbert wrote:
> * Eric Blake (eblake@redhat.com) wrote:
>> 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.
>>

>>  ##
>> +# @ShutdownCause:
>> +#
>> +# 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
> 
> It's a little coarse grained;  is there anyway to pass platform specific information
> for debug?  I ask because I spent a while debugging a few bugs with unexpected
> resets and had to figure out which of x86's many reset causes triggered it.

I'm open to any followup patches that add further enum values and
adjusts the various callers (patch 3 shows how MANY callers use
qemu_system_shutdown_request).  But I don't think it's necessarily in
scope for this series - remember, my goal here was merely to distinguish
between host- and guest-triggered resets (which libvirt and higher
management tasks want to know), rather than which of multiple reset
paths was taken (I agree that it is useful during a qemu debug session -
but that's a different audience).  I also don't consider myself an
expert in the many ways that x86 can reset - it was easy to blindly
rewrite qemu_system_shutdown_request() into
qemu_system_shutdown_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN) based solely
on directory, but it would be harder to distinguish which of the
multiple files should have which finer-grained cause.

-- 
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 --]