[Qemu-devel] [PATCH v2 1/3] qapi: Turn ShutdownCause into QAPI enum

Dominik Csapak posted 3 patches 6 years, 11 months ago
There is a newer version of this series
[Qemu-devel] [PATCH v2 1/3] qapi: Turn ShutdownCause into QAPI enum
Posted by Dominik Csapak 6 years, 11 months ago
Needed so the patch after next can add ShutdownCause to QMP events
SHUTDOWN and RESET.

Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
---
 include/sysemu/sysemu.h | 20 --------------------
 qapi/run-state.json     | 34 ++++++++++++++++++++++++++++++++++
 2 files changed, 34 insertions(+), 20 deletions(-)

diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 8d6095d98b..f83522c7e7 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -31,26 +31,6 @@ VMChangeStateEntry *qemu_add_vm_change_state_handler(VMChangeStateHandler *cb,
 void qemu_del_vm_change_state_handler(VMChangeStateEntry *e);
 void vm_state_notify(int running, RunState state);
 
-/* Enumeration of various causes for shutdown. */
-typedef enum ShutdownCause {
-    SHUTDOWN_CAUSE_NONE,          /* No shutdown request pending */
-    SHUTDOWN_CAUSE_HOST_ERROR,    /* An error prevents further use of guest */
-    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_GUEST_SHUTDOWN,/* Guest shutdown/suspend request, via
-                                     ACPI or other hardware-specific means */
-    SHUTDOWN_CAUSE_GUEST_RESET,   /* Guest reset request, and command line
-                                     turns that into a shutdown */
-    SHUTDOWN_CAUSE_GUEST_PANIC,   /* Guest panicked, and command line turns
-                                     that into a shutdown */
-    SHUTDOWN_CAUSE_SUBSYSTEM_RESET,/* Partial guest reset that does not trigger
-                                      QMP events and ignores --no-reboot. This
-                                      is useful for sanitize hypercalls on s390
-                                      that are used during kexec/kdump/boot */
-    SHUTDOWN_CAUSE__MAX,
-} ShutdownCause;
-
 static inline bool shutdown_caused_by_guest(ShutdownCause cause)
 {
     return cause >= SHUTDOWN_CAUSE_GUEST_SHUTDOWN;
diff --git a/qapi/run-state.json b/qapi/run-state.json
index 332e44897b..de7725bf09 100644
--- a/qapi/run-state.json
+++ b/qapi/run-state.json
@@ -60,6 +60,40 @@
             'guest-panicked', 'colo', 'preconfig' ] }
 
 ##
+# @ShutdownCause:
+#
+# An enumeration of reasons for a Shutdown.
+#
+# @none: No shutdown request pending
+#
+# @host-error: An error prevents further use of guest
+#
+# @host-qmp: Reaction to a QMP command, like 'quit'
+#
+# @host-signal: Reaction to a signal, such as SIGINT
+#
+# @host-ui: Reaction to a UI event, like window close
+#
+# @guest-shutdown: Guest shutdown/suspend request, via ACPI or other
+#                  hardware-specific means
+#
+# @guest-reset: Guest reset request, and command line turns that into
+#               a shutdown
+#
+# @guest-panic: Guest panicked, and command line turns that into a shutdown
+#
+# @subsystem-reset: Partial guest reset that does not trigger QMP events and
+#                  ignores --no-reboot. This is useful for sanitizing
+#                  hypercalls on s390 that are used during kexec/kdump/boot
+#
+##
+{ 'enum': 'ShutdownCause',
+  # Beware, shutdown_caused_by_guest() depends on enumeration order
+  'data': [ 'none', 'host-error', 'host-qmp', 'host-signal', 'host-ui',
+            'guest-shutdown', 'guest-reset', 'guest-panic',
+            'subsystem-reset'] }
+
+##
 # @StatusInfo:
 #
 # Information about VCPU run state
-- 
2.11.0



Re: [Qemu-devel] [PATCH v2 1/3] qapi: Turn ShutdownCause into QAPI enum
Posted by Markus Armbruster 6 years, 11 months ago
Dominik Csapak <d.csapak@proxmox.com> writes:

> Needed so the patch after next can add ShutdownCause to QMP events
> SHUTDOWN and RESET.
>
> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>

Reviewed-by: Markus Armbruster <armbru@redhat.com>

Re: [Qemu-devel] [PATCH v2 1/3] qapi: Turn ShutdownCause into QAPI enum
Posted by Eric Blake 6 years, 11 months ago
On 12/3/18 3:26 AM, Dominik Csapak wrote:
> Needed so the patch after next can add ShutdownCause to QMP events
> SHUTDOWN and RESET.
> 
> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
> ---
>   include/sysemu/sysemu.h | 20 --------------------
>   qapi/run-state.json     | 34 ++++++++++++++++++++++++++++++++++
>   2 files changed, 34 insertions(+), 20 deletions(-)

> +++ b/qapi/run-state.json

> +# @subsystem-reset: Partial guest reset that does not trigger QMP events and
> +#                  ignores --no-reboot. This is useful for sanitizing
> +#                  hypercalls on s390 that are used during kexec/kdump/boot

Is it ever possible for a user to see this state, or is the intent that 
it is internal-only?  But it's not the first time we've leaked internal 
states into enums (see, for example, 'null' within JobStatus in 
job.json), so it's not a showstopper.

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

Re: [Qemu-devel] [PATCH v2 1/3] qapi: Turn ShutdownCause into QAPI enum
Posted by Dominik Csapak 6 years, 11 months ago
On 12/3/18 10:34 PM, Eric Blake wrote:
> On 12/3/18 3:26 AM, Dominik Csapak wrote:
>> Needed so the patch after next can add ShutdownCause to QMP events
>> SHUTDOWN and RESET.
>>
>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>> ---
>>   include/sysemu/sysemu.h | 20 --------------------
>>   qapi/run-state.json     | 34 ++++++++++++++++++++++++++++++++++
>>   2 files changed, 34 insertions(+), 20 deletions(-)
> 
>> +++ b/qapi/run-state.json
> 
>> +# @subsystem-reset: Partial guest reset that does not trigger QMP 
>> events and
>> +#                  ignores --no-reboot. This is useful for sanitizing
>> +#                  hypercalls on s390 that are used during 
>> kexec/kdump/boot
> 
> Is it ever possible for a user to see this state, or is the intent that 
> it is internal-only?  But it's not the first time we've leaked internal 
> states into enums (see, for example, 'null' within JobStatus in 
> job.json), so it's not a showstopper.
> 

afaics, it is not possible to get this via an event, but i wanted
to keep the comment somehow.
should i mark it with an '(internal only)' or something similar?