2017-08-24 22:13:57 +03:00
|
|
|
# -*- Mode: Python -*-
|
2020-07-29 21:50:24 +03:00
|
|
|
# vim: filetype=python
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
|
|
|
|
|
|
|
##
|
|
|
|
# = VM run state
|
|
|
|
##
|
|
|
|
|
|
|
|
##
|
|
|
|
# @RunState:
|
|
|
|
#
|
|
|
|
# An enumeration of VM run states.
|
|
|
|
#
|
|
|
|
# @debug: QEMU is running on a debugger
|
|
|
|
#
|
|
|
|
# @finish-migrate: guest is paused to finish the migration process
|
|
|
|
#
|
|
|
|
# @inmigrate: guest is paused waiting for an incoming migration. Note
|
2023-04-28 13:54:29 +03:00
|
|
|
# that this state does not tell whether the machine will start at
|
|
|
|
# the end of the migration. This depends on the command-line -S
|
|
|
|
# option and any invocation of 'stop' or 'cont' that has happened
|
|
|
|
# since QEMU was started.
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @internal-error: An internal error that prevents further guest
|
|
|
|
# execution has occurred
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @io-error: the last IOP has failed and the device is configured to
|
|
|
|
# pause on I/O errors
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
|
|
|
# @paused: guest has been paused via the 'stop' command
|
|
|
|
#
|
|
|
|
# @postmigrate: guest is paused following a successful 'migrate'
|
|
|
|
#
|
|
|
|
# @prelaunch: QEMU was started with -S and guest has not started
|
|
|
|
#
|
|
|
|
# @restore-vm: guest is paused to restore VM state
|
|
|
|
#
|
|
|
|
# @running: guest is actively running
|
|
|
|
#
|
|
|
|
# @save-vm: guest is paused to save the VM state
|
|
|
|
#
|
|
|
|
# @shutdown: guest is shut down (and -no-shutdown is in use)
|
|
|
|
#
|
|
|
|
# @suspended: guest is suspended (ACPI S3)
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @watchdog: the watchdog action is configured to pause and has been
|
|
|
|
# triggered
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @guest-panicked: guest has been panicked as a result of guest OS
|
|
|
|
# panic
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @colo: guest is paused to save/restore VM state under colo
|
|
|
|
# checkpoint, VM can not get into this state unless colo
|
|
|
|
# capability is enabled for migration. (since 2.8)
|
2017-08-24 22:13:57 +03:00
|
|
|
##
|
|
|
|
{ 'enum': 'RunState',
|
|
|
|
'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
|
|
|
|
'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
|
|
|
|
'running', 'save-vm', 'shutdown', 'suspended', 'watchdog',
|
2020-10-27 11:44:18 +03:00
|
|
|
'guest-panicked', 'colo' ] }
|
2017-08-24 22:13:57 +03:00
|
|
|
|
2018-12-05 14:01:29 +03:00
|
|
|
##
|
|
|
|
# @ShutdownCause:
|
|
|
|
#
|
|
|
|
# An enumeration of reasons for a Shutdown.
|
|
|
|
#
|
|
|
|
# @none: No shutdown request pending
|
|
|
|
#
|
|
|
|
# @host-error: An error prevents further use of guest
|
|
|
|
#
|
2018-12-05 14:01:31 +03:00
|
|
|
# @host-qmp-quit: Reaction to the QMP command 'quit'
|
|
|
|
#
|
|
|
|
# @host-qmp-system-reset: Reaction to the QMP command 'system_reset'
|
2018-12-05 14:01:29 +03:00
|
|
|
#
|
|
|
|
# @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
|
2023-04-28 13:54:29 +03:00
|
|
|
# hardware-specific means
|
2018-12-05 14:01:29 +03:00
|
|
|
#
|
|
|
|
# @guest-reset: Guest reset request, and command line turns that into
|
2023-04-28 13:54:29 +03:00
|
|
|
# a shutdown
|
2018-12-05 14:01:29 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @guest-panic: Guest panicked, and command line turns that into a
|
|
|
|
# shutdown
|
2018-12-05 14:01:29 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @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
|
2018-12-05 14:01:29 +03:00
|
|
|
#
|
2022-10-25 03:43:17 +03:00
|
|
|
# @snapshot-load: A snapshot is being loaded by the record & replay
|
2023-04-28 13:54:29 +03:00
|
|
|
# subsystem. This value is used only within QEMU. It doesn't
|
2024-03-22 17:09:09 +03:00
|
|
|
# occur in QMP. (since 7.2)
|
2018-12-05 14:01:29 +03:00
|
|
|
##
|
|
|
|
{ 'enum': 'ShutdownCause',
|
|
|
|
# Beware, shutdown_caused_by_guest() depends on enumeration order
|
2018-12-05 14:01:31 +03:00
|
|
|
'data': [ 'none', 'host-error', 'host-qmp-quit', 'host-qmp-system-reset',
|
|
|
|
'host-signal', 'host-ui', 'guest-shutdown', 'guest-reset',
|
2022-10-25 03:43:17 +03:00
|
|
|
'guest-panic', 'subsystem-reset', 'snapshot-load'] }
|
2018-12-05 14:01:29 +03:00
|
|
|
|
2017-08-24 22:13:57 +03:00
|
|
|
##
|
|
|
|
# @StatusInfo:
|
|
|
|
#
|
2024-01-03 23:05:31 +03:00
|
|
|
# Information about VM run state
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
|
|
|
# @running: true if all VCPUs are runnable, false if not runnable
|
|
|
|
#
|
|
|
|
# @status: the virtual machine @RunState
|
|
|
|
#
|
2022-05-03 10:37:35 +03:00
|
|
|
# Since: 0.14
|
2017-08-24 22:13:57 +03:00
|
|
|
##
|
|
|
|
{ 'struct': 'StatusInfo',
|
2023-04-17 19:40:41 +03:00
|
|
|
'data': {'running': 'bool',
|
|
|
|
'status': 'RunState'} }
|
2017-08-24 22:13:57 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @query-status:
|
|
|
|
#
|
2024-01-03 23:05:31 +03:00
|
|
|
# Query the run status of the VM
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-01-03 23:05:31 +03:00
|
|
|
# Returns: @StatusInfo reflecting the VM
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2022-05-03 10:37:35 +03:00
|
|
|
# Since: 0.14
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-07-17 05:13:08 +03:00
|
|
|
# .. qmp-example::
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-02-16 17:58:34 +03:00
|
|
|
# -> { "execute": "query-status" }
|
|
|
|
# <- { "return": { "running": true,
|
|
|
|
# "status": "running" } }
|
2017-08-24 22:13:57 +03:00
|
|
|
##
|
2018-05-11 19:51:43 +03:00
|
|
|
{ 'command': 'query-status', 'returns': 'StatusInfo',
|
|
|
|
'allow-preconfig': true }
|
2017-08-24 22:13:57 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @SHUTDOWN:
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# Emitted when the virtual machine has shut down, indicating that qemu
|
|
|
|
# is about to exit.
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @guest: If true, the shutdown was triggered by a guest request (such
|
|
|
|
# as a guest-initiated ACPI shutdown request or other
|
|
|
|
# hardware-specific action) rather than a host request (such as
|
2024-03-22 17:09:09 +03:00
|
|
|
# sending qemu a SIGINT). (since 2.10)
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-03-22 17:09:08 +03:00
|
|
|
# @reason: The @ShutdownCause which resulted in the SHUTDOWN.
|
|
|
|
# (since 4.0)
|
2018-12-05 14:01:30 +03:00
|
|
|
#
|
2024-06-27 01:21:18 +03:00
|
|
|
# .. note:: If the command-line option ``-no-shutdown`` has been
|
qapi: convert "Note" sections to plain rST
We do not need a dedicated section for notes. By eliminating a specially
parsed section, these notes can be treated as normal rST paragraphs in
the new QMP reference manual, and can be placed and styled much more
flexibly.
Convert all existing "Note" and "Notes" sections to pure rST. As part of
the conversion, capitalize the first letter of each sentence and add
trailing punctuation where appropriate to ensure notes look sensible and
consistent in rendered HTML documentation. Markup is also re-aligned to
the de-facto standard of 3 spaces for directives.
Update docs/devel/qapi-code-gen.rst to reflect the new paradigm, and
update the QAPI parser to prohibit "Note" sections while suggesting a
new syntax. The exact formatting to use is a matter of taste, but a good
candidate is simply:
.. note:: lorem ipsum ...
... dolor sit amet ...
... consectetur adipiscing elit ...
... but there are other choices, too. The Sphinx readthedocs theme
offers theming for the following forms (capitalization unimportant); all
are adorned with a (!) symbol () in the title bar for rendered HTML
docs.
See
https://sphinx-rtd-theme.readthedocs.io/en/stable/demo/demo.html#admonitions
for examples of each directive/admonition in use.
These are rendered in orange:
.. Attention:: ...
.. Caution:: ...
.. WARNING:: ...
These are rendered in red:
.. DANGER:: ...
.. Error:: ...
These are rendered in green:
.. Hint:: ...
.. Important:: ...
.. Tip:: ...
These are rendered in blue:
.. Note:: ...
.. admonition:: custom title
admonition body text
This patch uses ".. note::" almost everywhere, with just two "caution"
directives. Several instances of "Notes:" have been converted to
merely ".. note::", or multiple ".. note::" where appropriate.
".. admonition:: notes" is used in a few places where we had an
ordered list of multiple notes that would not make sense as
standalone/separate admonitions. Two "Note:" following "Example:"
have been turned into ordinary paragraphs within the example.
NOTE: Because qapidoc.py does not attempt to preserve source ordering of
sections, the conversion of Notes from a "tagged section" to an
"untagged section" means that rendering order for some notes *may
change* as a result of this patch. The forthcoming qapidoc.py rewrite
strictly preserves source ordering in the rendered documentation, so
this issue will be rectified in the new generator.
Signed-off-by: John Snow <jsnow@redhat.com>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com> [for block*.json]
Message-ID: <20240626222128.406106-11-jsnow@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
[Commit message clarified slightly, period added to one more note]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2024-06-27 01:21:16 +03:00
|
|
|
# specified, qemu will not exit, and a STOP event will eventually
|
|
|
|
# follow the SHUTDOWN event.
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2020-11-18 09:41:58 +03:00
|
|
|
# Since: 0.12
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-07-17 05:13:08 +03:00
|
|
|
# .. qmp-example::
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-02-16 17:58:34 +03:00
|
|
|
# <- { "event": "SHUTDOWN",
|
|
|
|
# "data": { "guest": true, "reason": "guest-shutdown" },
|
|
|
|
# "timestamp": { "seconds": 1267040730, "microseconds": 682951 } }
|
2017-08-24 22:13:57 +03:00
|
|
|
##
|
2018-12-05 14:01:30 +03:00
|
|
|
{ 'event': 'SHUTDOWN', 'data': { 'guest': 'bool', 'reason': 'ShutdownCause' } }
|
2017-08-24 22:13:57 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @POWERDOWN:
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# Emitted when the virtual machine is powered down through the power
|
|
|
|
# control system, such as via ACPI.
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2020-11-18 09:41:58 +03:00
|
|
|
# Since: 0.12
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-07-17 05:13:08 +03:00
|
|
|
# .. qmp-example::
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-02-16 17:58:34 +03:00
|
|
|
# <- { "event": "POWERDOWN",
|
|
|
|
# "timestamp": { "seconds": 1267040730, "microseconds": 682951 } }
|
2017-08-24 22:13:57 +03:00
|
|
|
##
|
|
|
|
{ 'event': 'POWERDOWN' }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @RESET:
|
|
|
|
#
|
|
|
|
# Emitted when the virtual machine is reset
|
|
|
|
#
|
|
|
|
# @guest: If true, the reset was triggered by a guest request (such as
|
2023-04-28 13:54:29 +03:00
|
|
|
# a guest-initiated ACPI reboot request or other hardware-specific
|
|
|
|
# action) rather than a host request (such as the QMP command
|
2024-03-22 17:09:09 +03:00
|
|
|
# system_reset). (since 2.10)
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-03-22 17:09:09 +03:00
|
|
|
# @reason: The @ShutdownCause of the RESET. (since 4.0)
|
2018-12-05 14:01:30 +03:00
|
|
|
#
|
2020-11-18 09:41:58 +03:00
|
|
|
# Since: 0.12
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-07-17 05:13:08 +03:00
|
|
|
# .. qmp-example::
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-02-16 17:58:34 +03:00
|
|
|
# <- { "event": "RESET",
|
|
|
|
# "data": { "guest": false, "reason": "guest-reset" },
|
|
|
|
# "timestamp": { "seconds": 1267041653, "microseconds": 9518 } }
|
2017-08-24 22:13:57 +03:00
|
|
|
##
|
2018-12-05 14:01:30 +03:00
|
|
|
{ 'event': 'RESET', 'data': { 'guest': 'bool', 'reason': 'ShutdownCause' } }
|
2017-08-24 22:13:57 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @STOP:
|
|
|
|
#
|
|
|
|
# Emitted when the virtual machine is stopped
|
|
|
|
#
|
2020-11-18 09:41:58 +03:00
|
|
|
# Since: 0.12
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-07-17 05:13:08 +03:00
|
|
|
# .. qmp-example::
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-02-16 17:58:34 +03:00
|
|
|
# <- { "event": "STOP",
|
|
|
|
# "timestamp": { "seconds": 1267041730, "microseconds": 281295 } }
|
2017-08-24 22:13:57 +03:00
|
|
|
##
|
|
|
|
{ 'event': 'STOP' }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @RESUME:
|
|
|
|
#
|
|
|
|
# Emitted when the virtual machine resumes execution
|
|
|
|
#
|
2020-11-18 09:41:58 +03:00
|
|
|
# Since: 0.12
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-07-17 05:13:08 +03:00
|
|
|
# .. qmp-example::
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-02-16 17:58:34 +03:00
|
|
|
# <- { "event": "RESUME",
|
|
|
|
# "timestamp": { "seconds": 1271770767, "microseconds": 582542 } }
|
2017-08-24 22:13:57 +03:00
|
|
|
##
|
|
|
|
{ 'event': 'RESUME' }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @SUSPEND:
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# Emitted when guest enters a hardware suspension state, for example,
|
|
|
|
# S3 state, which is sometimes called standby state
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
|
|
|
# Since: 1.1
|
|
|
|
#
|
2024-07-17 05:13:08 +03:00
|
|
|
# .. qmp-example::
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-02-16 17:58:34 +03:00
|
|
|
# <- { "event": "SUSPEND",
|
|
|
|
# "timestamp": { "seconds": 1344456160, "microseconds": 309119 } }
|
2017-08-24 22:13:57 +03:00
|
|
|
##
|
|
|
|
{ 'event': 'SUSPEND' }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @SUSPEND_DISK:
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# Emitted when guest enters a hardware suspension state with data
|
|
|
|
# saved on disk, for example, S4 state, which is sometimes called
|
|
|
|
# hibernate state
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
qapi: convert "Note" sections to plain rST
We do not need a dedicated section for notes. By eliminating a specially
parsed section, these notes can be treated as normal rST paragraphs in
the new QMP reference manual, and can be placed and styled much more
flexibly.
Convert all existing "Note" and "Notes" sections to pure rST. As part of
the conversion, capitalize the first letter of each sentence and add
trailing punctuation where appropriate to ensure notes look sensible and
consistent in rendered HTML documentation. Markup is also re-aligned to
the de-facto standard of 3 spaces for directives.
Update docs/devel/qapi-code-gen.rst to reflect the new paradigm, and
update the QAPI parser to prohibit "Note" sections while suggesting a
new syntax. The exact formatting to use is a matter of taste, but a good
candidate is simply:
.. note:: lorem ipsum ...
... dolor sit amet ...
... consectetur adipiscing elit ...
... but there are other choices, too. The Sphinx readthedocs theme
offers theming for the following forms (capitalization unimportant); all
are adorned with a (!) symbol () in the title bar for rendered HTML
docs.
See
https://sphinx-rtd-theme.readthedocs.io/en/stable/demo/demo.html#admonitions
for examples of each directive/admonition in use.
These are rendered in orange:
.. Attention:: ...
.. Caution:: ...
.. WARNING:: ...
These are rendered in red:
.. DANGER:: ...
.. Error:: ...
These are rendered in green:
.. Hint:: ...
.. Important:: ...
.. Tip:: ...
These are rendered in blue:
.. Note:: ...
.. admonition:: custom title
admonition body text
This patch uses ".. note::" almost everywhere, with just two "caution"
directives. Several instances of "Notes:" have been converted to
merely ".. note::", or multiple ".. note::" where appropriate.
".. admonition:: notes" is used in a few places where we had an
ordered list of multiple notes that would not make sense as
standalone/separate admonitions. Two "Note:" following "Example:"
have been turned into ordinary paragraphs within the example.
NOTE: Because qapidoc.py does not attempt to preserve source ordering of
sections, the conversion of Notes from a "tagged section" to an
"untagged section" means that rendering order for some notes *may
change* as a result of this patch. The forthcoming qapidoc.py rewrite
strictly preserves source ordering in the rendered documentation, so
this issue will be rectified in the new generator.
Signed-off-by: John Snow <jsnow@redhat.com>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com> [for block*.json]
Message-ID: <20240626222128.406106-11-jsnow@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
[Commit message clarified slightly, period added to one more note]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2024-06-27 01:21:16 +03:00
|
|
|
# .. note:: QEMU shuts down (similar to event @SHUTDOWN) when entering
|
|
|
|
# this state.
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
|
|
|
# Since: 1.2
|
|
|
|
#
|
2024-07-17 05:13:08 +03:00
|
|
|
# .. qmp-example::
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-02-16 17:58:34 +03:00
|
|
|
# <- { "event": "SUSPEND_DISK",
|
|
|
|
# "timestamp": { "seconds": 1344456160, "microseconds": 309119 } }
|
2017-08-24 22:13:57 +03:00
|
|
|
##
|
|
|
|
{ 'event': 'SUSPEND_DISK' }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @WAKEUP:
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# Emitted when the guest has woken up from suspend state and is
|
|
|
|
# running
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
|
|
|
# Since: 1.1
|
|
|
|
#
|
2024-07-17 05:13:08 +03:00
|
|
|
# .. qmp-example::
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-02-16 17:58:34 +03:00
|
|
|
# <- { "event": "WAKEUP",
|
|
|
|
# "timestamp": { "seconds": 1344522075, "microseconds": 745528 } }
|
2017-08-24 22:13:57 +03:00
|
|
|
##
|
|
|
|
{ 'event': 'WAKEUP' }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @WATCHDOG:
|
|
|
|
#
|
|
|
|
# Emitted when the watchdog device's timer is expired
|
|
|
|
#
|
|
|
|
# @action: action that has been taken
|
|
|
|
#
|
qapi: convert "Note" sections to plain rST
We do not need a dedicated section for notes. By eliminating a specially
parsed section, these notes can be treated as normal rST paragraphs in
the new QMP reference manual, and can be placed and styled much more
flexibly.
Convert all existing "Note" and "Notes" sections to pure rST. As part of
the conversion, capitalize the first letter of each sentence and add
trailing punctuation where appropriate to ensure notes look sensible and
consistent in rendered HTML documentation. Markup is also re-aligned to
the de-facto standard of 3 spaces for directives.
Update docs/devel/qapi-code-gen.rst to reflect the new paradigm, and
update the QAPI parser to prohibit "Note" sections while suggesting a
new syntax. The exact formatting to use is a matter of taste, but a good
candidate is simply:
.. note:: lorem ipsum ...
... dolor sit amet ...
... consectetur adipiscing elit ...
... but there are other choices, too. The Sphinx readthedocs theme
offers theming for the following forms (capitalization unimportant); all
are adorned with a (!) symbol () in the title bar for rendered HTML
docs.
See
https://sphinx-rtd-theme.readthedocs.io/en/stable/demo/demo.html#admonitions
for examples of each directive/admonition in use.
These are rendered in orange:
.. Attention:: ...
.. Caution:: ...
.. WARNING:: ...
These are rendered in red:
.. DANGER:: ...
.. Error:: ...
These are rendered in green:
.. Hint:: ...
.. Important:: ...
.. Tip:: ...
These are rendered in blue:
.. Note:: ...
.. admonition:: custom title
admonition body text
This patch uses ".. note::" almost everywhere, with just two "caution"
directives. Several instances of "Notes:" have been converted to
merely ".. note::", or multiple ".. note::" where appropriate.
".. admonition:: notes" is used in a few places where we had an
ordered list of multiple notes that would not make sense as
standalone/separate admonitions. Two "Note:" following "Example:"
have been turned into ordinary paragraphs within the example.
NOTE: Because qapidoc.py does not attempt to preserve source ordering of
sections, the conversion of Notes from a "tagged section" to an
"untagged section" means that rendering order for some notes *may
change* as a result of this patch. The forthcoming qapidoc.py rewrite
strictly preserves source ordering in the rendered documentation, so
this issue will be rectified in the new generator.
Signed-off-by: John Snow <jsnow@redhat.com>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com> [for block*.json]
Message-ID: <20240626222128.406106-11-jsnow@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
[Commit message clarified slightly, period added to one more note]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2024-06-27 01:21:16 +03:00
|
|
|
# .. note:: If action is "reset", "shutdown", or "pause" the WATCHDOG
|
|
|
|
# event is followed respectively by the RESET, SHUTDOWN, or STOP
|
|
|
|
# events.
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
qapi: convert "Note" sections to plain rST
We do not need a dedicated section for notes. By eliminating a specially
parsed section, these notes can be treated as normal rST paragraphs in
the new QMP reference manual, and can be placed and styled much more
flexibly.
Convert all existing "Note" and "Notes" sections to pure rST. As part of
the conversion, capitalize the first letter of each sentence and add
trailing punctuation where appropriate to ensure notes look sensible and
consistent in rendered HTML documentation. Markup is also re-aligned to
the de-facto standard of 3 spaces for directives.
Update docs/devel/qapi-code-gen.rst to reflect the new paradigm, and
update the QAPI parser to prohibit "Note" sections while suggesting a
new syntax. The exact formatting to use is a matter of taste, but a good
candidate is simply:
.. note:: lorem ipsum ...
... dolor sit amet ...
... consectetur adipiscing elit ...
... but there are other choices, too. The Sphinx readthedocs theme
offers theming for the following forms (capitalization unimportant); all
are adorned with a (!) symbol () in the title bar for rendered HTML
docs.
See
https://sphinx-rtd-theme.readthedocs.io/en/stable/demo/demo.html#admonitions
for examples of each directive/admonition in use.
These are rendered in orange:
.. Attention:: ...
.. Caution:: ...
.. WARNING:: ...
These are rendered in red:
.. DANGER:: ...
.. Error:: ...
These are rendered in green:
.. Hint:: ...
.. Important:: ...
.. Tip:: ...
These are rendered in blue:
.. Note:: ...
.. admonition:: custom title
admonition body text
This patch uses ".. note::" almost everywhere, with just two "caution"
directives. Several instances of "Notes:" have been converted to
merely ".. note::", or multiple ".. note::" where appropriate.
".. admonition:: notes" is used in a few places where we had an
ordered list of multiple notes that would not make sense as
standalone/separate admonitions. Two "Note:" following "Example:"
have been turned into ordinary paragraphs within the example.
NOTE: Because qapidoc.py does not attempt to preserve source ordering of
sections, the conversion of Notes from a "tagged section" to an
"untagged section" means that rendering order for some notes *may
change* as a result of this patch. The forthcoming qapidoc.py rewrite
strictly preserves source ordering in the rendered documentation, so
this issue will be rectified in the new generator.
Signed-off-by: John Snow <jsnow@redhat.com>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com> [for block*.json]
Message-ID: <20240626222128.406106-11-jsnow@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
[Commit message clarified slightly, period added to one more note]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2024-06-27 01:21:16 +03:00
|
|
|
# .. note:: This event is rate-limited.
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2020-11-18 09:41:58 +03:00
|
|
|
# Since: 0.13
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-07-17 05:13:08 +03:00
|
|
|
# .. qmp-example::
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-02-16 17:58:34 +03:00
|
|
|
# <- { "event": "WATCHDOG",
|
|
|
|
# "data": { "action": "reset" },
|
|
|
|
# "timestamp": { "seconds": 1267061043, "microseconds": 959568 } }
|
2017-08-24 22:13:57 +03:00
|
|
|
##
|
|
|
|
{ 'event': 'WATCHDOG',
|
2017-09-07 11:05:24 +03:00
|
|
|
'data': { 'action': 'WatchdogAction' } }
|
2017-08-24 22:13:57 +03:00
|
|
|
|
|
|
|
##
|
2017-09-07 11:05:24 +03:00
|
|
|
# @WatchdogAction:
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# An enumeration of the actions taken when the watchdog device's timer
|
|
|
|
# is expired
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
|
|
|
# @reset: system resets
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @shutdown: system shutdown, note that it is similar to @powerdown,
|
|
|
|
# which tries to set to system status and notify guest
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
|
|
|
# @poweroff: system poweroff, the emulator program exits
|
|
|
|
#
|
|
|
|
# @pause: system pauses, similar to @stop
|
|
|
|
#
|
|
|
|
# @debug: system enters debug state
|
|
|
|
#
|
|
|
|
# @none: nothing is done
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @inject-nmi: a non-maskable interrupt is injected into the first
|
|
|
|
# VCPU (all VCPUS on x86) (since 2.4)
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
|
|
|
# Since: 2.1
|
|
|
|
##
|
2017-09-07 11:05:24 +03:00
|
|
|
{ 'enum': 'WatchdogAction',
|
2017-08-24 22:13:57 +03:00
|
|
|
'data': [ 'reset', 'shutdown', 'poweroff', 'pause', 'debug', 'none',
|
|
|
|
'inject-nmi' ] }
|
|
|
|
|
2020-12-11 19:52:43 +03:00
|
|
|
##
|
|
|
|
# @RebootAction:
|
|
|
|
#
|
|
|
|
# Possible QEMU actions upon guest reboot
|
|
|
|
#
|
2021-01-20 16:30:27 +03:00
|
|
|
# @reset: Reset the VM
|
2020-12-11 19:52:43 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @shutdown: Shutdown the VM and exit, according to the shutdown
|
|
|
|
# action
|
2020-12-11 19:52:43 +03:00
|
|
|
#
|
|
|
|
# Since: 6.0
|
|
|
|
##
|
|
|
|
{ 'enum': 'RebootAction',
|
2021-01-20 16:30:27 +03:00
|
|
|
'data': [ 'reset', 'shutdown' ] }
|
2020-12-11 19:52:43 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @ShutdownAction:
|
|
|
|
#
|
|
|
|
# Possible QEMU actions upon guest shutdown
|
|
|
|
#
|
|
|
|
# @poweroff: Shutdown the VM and exit
|
|
|
|
#
|
2022-05-03 10:37:30 +03:00
|
|
|
# @pause: pause the VM
|
2020-12-11 19:52:43 +03:00
|
|
|
#
|
|
|
|
# Since: 6.0
|
|
|
|
##
|
|
|
|
{ 'enum': 'ShutdownAction',
|
|
|
|
'data': [ 'poweroff', 'pause' ] }
|
|
|
|
|
2020-12-12 01:31:52 +03:00
|
|
|
##
|
|
|
|
# @PanicAction:
|
|
|
|
#
|
|
|
|
# @none: Continue VM execution
|
|
|
|
#
|
|
|
|
# @pause: Pause the VM
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @shutdown: Shutdown the VM and exit, according to the shutdown
|
|
|
|
# action
|
2021-01-20 16:30:27 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @exit-failure: Shutdown the VM and exit with nonzero status (since
|
|
|
|
# 7.1)
|
2022-07-26 01:37:45 +03:00
|
|
|
#
|
2020-12-12 01:31:52 +03:00
|
|
|
# Since: 6.0
|
|
|
|
##
|
|
|
|
{ 'enum': 'PanicAction',
|
2022-07-26 01:37:45 +03:00
|
|
|
'data': [ 'pause', 'shutdown', 'exit-failure', 'none' ] }
|
2020-12-12 01:31:52 +03:00
|
|
|
|
2018-02-27 01:57:43 +03:00
|
|
|
##
|
|
|
|
# @watchdog-set-action:
|
|
|
|
#
|
2024-03-25 13:45:02 +03:00
|
|
|
# Set watchdog action.
|
|
|
|
#
|
|
|
|
# @action: @WatchdogAction action taken when watchdog timer expires.
|
2018-02-27 01:57:43 +03:00
|
|
|
#
|
|
|
|
# Since: 2.11
|
2024-03-25 13:45:02 +03:00
|
|
|
#
|
2024-07-17 05:13:08 +03:00
|
|
|
# .. qmp-example::
|
2024-03-25 13:45:02 +03:00
|
|
|
#
|
|
|
|
# -> { "execute": "watchdog-set-action",
|
|
|
|
# "arguments": { "action": "inject-nmi" } }
|
|
|
|
# <- { "return": {} }
|
2018-02-27 01:57:43 +03:00
|
|
|
##
|
|
|
|
{ 'command': 'watchdog-set-action', 'data' : {'action': 'WatchdogAction'} }
|
|
|
|
|
2020-12-11 19:52:43 +03:00
|
|
|
##
|
|
|
|
# @set-action:
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# Set the actions that will be taken by the emulator in response to
|
|
|
|
# guest events.
|
2020-12-11 19:52:43 +03:00
|
|
|
#
|
|
|
|
# @reboot: @RebootAction action taken on guest reboot.
|
|
|
|
#
|
|
|
|
# @shutdown: @ShutdownAction action taken on guest shutdown.
|
|
|
|
#
|
2020-12-12 01:31:52 +03:00
|
|
|
# @panic: @PanicAction action taken on guest panic.
|
|
|
|
#
|
2024-02-27 14:39:13 +03:00
|
|
|
# @watchdog: @WatchdogAction action taken when watchdog timer expires.
|
2020-12-11 19:52:43 +03:00
|
|
|
#
|
|
|
|
# Since: 6.0
|
|
|
|
#
|
2024-07-17 05:13:08 +03:00
|
|
|
# .. qmp-example::
|
2020-12-11 19:52:43 +03:00
|
|
|
#
|
2024-02-16 17:58:34 +03:00
|
|
|
# -> { "execute": "set-action",
|
|
|
|
# "arguments": { "reboot": "shutdown",
|
|
|
|
# "shutdown" : "pause",
|
|
|
|
# "panic": "pause",
|
|
|
|
# "watchdog": "inject-nmi" } }
|
|
|
|
# <- { "return": {} }
|
2020-12-11 19:52:43 +03:00
|
|
|
##
|
|
|
|
{ 'command': 'set-action',
|
|
|
|
'data': { '*reboot': 'RebootAction',
|
|
|
|
'*shutdown': 'ShutdownAction',
|
2020-12-12 01:31:52 +03:00
|
|
|
'*panic': 'PanicAction',
|
2020-12-11 19:52:43 +03:00
|
|
|
'*watchdog': 'WatchdogAction' },
|
|
|
|
'allow-preconfig': true }
|
|
|
|
|
2017-08-24 22:13:57 +03:00
|
|
|
##
|
|
|
|
# @GUEST_PANICKED:
|
|
|
|
#
|
|
|
|
# Emitted when guest OS panic is detected
|
|
|
|
#
|
|
|
|
# @action: action that has been taken, currently always "pause"
|
|
|
|
#
|
|
|
|
# @info: information about a panic (since 2.9)
|
|
|
|
#
|
|
|
|
# Since: 1.5
|
|
|
|
#
|
2024-07-17 05:13:08 +03:00
|
|
|
# .. qmp-example::
|
2017-08-24 22:13:57 +03:00
|
|
|
#
|
2024-02-16 17:58:34 +03:00
|
|
|
# <- { "event": "GUEST_PANICKED",
|
|
|
|
# "data": { "action": "pause" },
|
|
|
|
# "timestamp": { "seconds": 1648245231, "microseconds": 900001 } }
|
2017-08-24 22:13:57 +03:00
|
|
|
##
|
|
|
|
{ 'event': 'GUEST_PANICKED',
|
|
|
|
'data': { 'action': 'GuestPanicAction', '*info': 'GuestPanicInformation' } }
|
|
|
|
|
2020-01-14 05:31:02 +03:00
|
|
|
##
|
|
|
|
# @GUEST_CRASHLOADED:
|
|
|
|
#
|
|
|
|
# Emitted when guest OS crash loaded is detected
|
|
|
|
#
|
|
|
|
# @action: action that has been taken, currently always "run"
|
|
|
|
#
|
|
|
|
# @info: information about a panic
|
|
|
|
#
|
|
|
|
# Since: 5.0
|
|
|
|
#
|
2024-07-17 05:13:08 +03:00
|
|
|
# .. qmp-example::
|
2020-01-14 05:31:02 +03:00
|
|
|
#
|
2024-02-16 17:58:34 +03:00
|
|
|
# <- { "event": "GUEST_CRASHLOADED",
|
|
|
|
# "data": { "action": "run" },
|
|
|
|
# "timestamp": { "seconds": 1648245259, "microseconds": 893771 } }
|
2020-01-14 05:31:02 +03:00
|
|
|
##
|
|
|
|
{ 'event': 'GUEST_CRASHLOADED',
|
|
|
|
'data': { 'action': 'GuestPanicAction', '*info': 'GuestPanicInformation' } }
|
|
|
|
|
2024-05-27 09:27:52 +03:00
|
|
|
##
|
|
|
|
# @GUEST_PVSHUTDOWN:
|
|
|
|
#
|
|
|
|
# Emitted when guest submits a shutdown request via pvpanic interface
|
|
|
|
#
|
|
|
|
# Since: 9.1
|
|
|
|
#
|
2024-07-17 05:13:08 +03:00
|
|
|
# .. qmp-example::
|
2024-05-27 09:27:52 +03:00
|
|
|
#
|
|
|
|
# <- { "event": "GUEST_PVSHUTDOWN",
|
|
|
|
# "timestamp": { "seconds": 1648245259, "microseconds": 893771 } }
|
|
|
|
##
|
|
|
|
{ 'event': 'GUEST_PVSHUTDOWN' }
|
|
|
|
|
2017-08-24 22:13:57 +03:00
|
|
|
##
|
|
|
|
# @GuestPanicAction:
|
|
|
|
#
|
|
|
|
# An enumeration of the actions taken when guest OS panic is detected
|
|
|
|
#
|
|
|
|
# @pause: system pauses
|
|
|
|
#
|
2023-04-25 09:42:20 +03:00
|
|
|
# @poweroff: system powers off (since 2.8)
|
|
|
|
#
|
|
|
|
# @run: system continues to run (since 5.0)
|
|
|
|
#
|
|
|
|
# Since: 2.1
|
2017-08-24 22:13:57 +03:00
|
|
|
##
|
|
|
|
{ 'enum': 'GuestPanicAction',
|
2020-01-14 05:31:02 +03:00
|
|
|
'data': [ 'pause', 'poweroff', 'run' ] }
|
2017-08-24 22:13:57 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @GuestPanicInformationType:
|
|
|
|
#
|
|
|
|
# An enumeration of the guest panic information types
|
|
|
|
#
|
s390x/cpu: expose the guest crash information
This patch is the s390 implementation of guest crash information,
similar to commit d187e08dc4 ("i386/cpu: add crash-information QOM
property") and the related commits. We will detect several crash
reasons, with the "disabled wait" being the most important one, since
this is used by all s390 guests as a "panic like" notification.
Demonstrate these ways with examples as follows.
1. crash-information QOM property;
Run qemu with -qmp unix:qmp-sock,server, then use utility "qmp-shell"
to execute "qom-get" command, and might get the result like,
(QEMU) (QEMU) qom-get path=/machine/unattached/device[0] \
property=crash-information
{"return": {"core": 0, "reason": "disabled-wait", "psw-mask": 562956395872256, \
"type": "s390", "psw-addr": 1102832}}
2. GUEST_PANICKED event reporting;
Run qemu with a socket option, and telnet or nc to that,
-chardev socket,id=qmp,port=4444,host=localhost,server \
-mon chardev=qmp,mode=control,pretty=on \
Negotiating the mode by { "execute": "qmp_capabilities" }, and the crash
information will be reported on a guest crash event like,
{
"timestamp": {
"seconds": 1518004739,
"microseconds": 552563
},
"event": "GUEST_PANICKED",
"data": {
"action": "pause",
"info": {
"core": 0,
"psw-addr": 1102832,
"reason": "disabled-wait",
"psw-mask": 562956395872256,
"type": "s390"
}
}
}
3. log;
Run qemu with the parameters: -D <logfile> -d guest_errors, to
specify the logfile and log item. The results might be,
Guest crashed on cpu 0: disabled-wait
PSW: 0x0002000180000000 0x000000000010d3f0
Co-authored-by: Jing Liu <liujbjl@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20180209122543.25755-1-borntraeger@de.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[CH: tweaked qapi comment]
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09 15:25:43 +03:00
|
|
|
# @hyper-v: hyper-v guest panic information type
|
|
|
|
#
|
|
|
|
# @s390: s390 guest panic information type (Since: 2.12)
|
|
|
|
#
|
2017-08-24 22:13:57 +03:00
|
|
|
# Since: 2.9
|
|
|
|
##
|
|
|
|
{ 'enum': 'GuestPanicInformationType',
|
s390x/cpu: expose the guest crash information
This patch is the s390 implementation of guest crash information,
similar to commit d187e08dc4 ("i386/cpu: add crash-information QOM
property") and the related commits. We will detect several crash
reasons, with the "disabled wait" being the most important one, since
this is used by all s390 guests as a "panic like" notification.
Demonstrate these ways with examples as follows.
1. crash-information QOM property;
Run qemu with -qmp unix:qmp-sock,server, then use utility "qmp-shell"
to execute "qom-get" command, and might get the result like,
(QEMU) (QEMU) qom-get path=/machine/unattached/device[0] \
property=crash-information
{"return": {"core": 0, "reason": "disabled-wait", "psw-mask": 562956395872256, \
"type": "s390", "psw-addr": 1102832}}
2. GUEST_PANICKED event reporting;
Run qemu with a socket option, and telnet or nc to that,
-chardev socket,id=qmp,port=4444,host=localhost,server \
-mon chardev=qmp,mode=control,pretty=on \
Negotiating the mode by { "execute": "qmp_capabilities" }, and the crash
information will be reported on a guest crash event like,
{
"timestamp": {
"seconds": 1518004739,
"microseconds": 552563
},
"event": "GUEST_PANICKED",
"data": {
"action": "pause",
"info": {
"core": 0,
"psw-addr": 1102832,
"reason": "disabled-wait",
"psw-mask": 562956395872256,
"type": "s390"
}
}
}
3. log;
Run qemu with the parameters: -D <logfile> -d guest_errors, to
specify the logfile and log item. The results might be,
Guest crashed on cpu 0: disabled-wait
PSW: 0x0002000180000000 0x000000000010d3f0
Co-authored-by: Jing Liu <liujbjl@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20180209122543.25755-1-borntraeger@de.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[CH: tweaked qapi comment]
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09 15:25:43 +03:00
|
|
|
'data': [ 'hyper-v', 's390' ] }
|
2017-08-24 22:13:57 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @GuestPanicInformation:
|
|
|
|
#
|
|
|
|
# Information about a guest panic
|
|
|
|
#
|
s390x/cpu: expose the guest crash information
This patch is the s390 implementation of guest crash information,
similar to commit d187e08dc4 ("i386/cpu: add crash-information QOM
property") and the related commits. We will detect several crash
reasons, with the "disabled wait" being the most important one, since
this is used by all s390 guests as a "panic like" notification.
Demonstrate these ways with examples as follows.
1. crash-information QOM property;
Run qemu with -qmp unix:qmp-sock,server, then use utility "qmp-shell"
to execute "qom-get" command, and might get the result like,
(QEMU) (QEMU) qom-get path=/machine/unattached/device[0] \
property=crash-information
{"return": {"core": 0, "reason": "disabled-wait", "psw-mask": 562956395872256, \
"type": "s390", "psw-addr": 1102832}}
2. GUEST_PANICKED event reporting;
Run qemu with a socket option, and telnet or nc to that,
-chardev socket,id=qmp,port=4444,host=localhost,server \
-mon chardev=qmp,mode=control,pretty=on \
Negotiating the mode by { "execute": "qmp_capabilities" }, and the crash
information will be reported on a guest crash event like,
{
"timestamp": {
"seconds": 1518004739,
"microseconds": 552563
},
"event": "GUEST_PANICKED",
"data": {
"action": "pause",
"info": {
"core": 0,
"psw-addr": 1102832,
"reason": "disabled-wait",
"psw-mask": 562956395872256,
"type": "s390"
}
}
}
3. log;
Run qemu with the parameters: -D <logfile> -d guest_errors, to
specify the logfile and log item. The results might be,
Guest crashed on cpu 0: disabled-wait
PSW: 0x0002000180000000 0x000000000010d3f0
Co-authored-by: Jing Liu <liujbjl@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20180209122543.25755-1-borntraeger@de.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[CH: tweaked qapi comment]
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09 15:25:43 +03:00
|
|
|
# @type: Crash type that defines the hypervisor specific information
|
|
|
|
#
|
2017-08-24 22:13:57 +03:00
|
|
|
# Since: 2.9
|
|
|
|
##
|
|
|
|
{'union': 'GuestPanicInformation',
|
|
|
|
'base': {'type': 'GuestPanicInformationType'},
|
|
|
|
'discriminator': 'type',
|
2023-04-28 13:54:29 +03:00
|
|
|
'data': {'hyper-v': 'GuestPanicInformationHyperV',
|
|
|
|
's390': 'GuestPanicInformationS390'}}
|
2017-08-24 22:13:57 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @GuestPanicInformationHyperV:
|
|
|
|
#
|
|
|
|
# Hyper-V specific guest panic information (HV crash MSRs)
|
|
|
|
#
|
2024-03-25 13:45:02 +03:00
|
|
|
# @arg1: for Windows, STOP code for the guest crash. For Linux,
|
2024-07-29 09:52:20 +03:00
|
|
|
# an error code.
|
2024-03-25 13:45:02 +03:00
|
|
|
#
|
|
|
|
# @arg2: for Windows, first argument of the STOP. For Linux, the
|
2024-07-29 09:52:20 +03:00
|
|
|
# guest OS ID, which has the kernel version in bits 16-47 and
|
|
|
|
# 0x8100 in bits 48-63.
|
2024-03-25 13:45:02 +03:00
|
|
|
#
|
|
|
|
# @arg3: for Windows, second argument of the STOP. For Linux, the
|
2024-07-29 09:52:20 +03:00
|
|
|
# program counter of the guest.
|
2024-03-25 13:45:02 +03:00
|
|
|
#
|
|
|
|
# @arg4: for Windows, third argument of the STOP. For Linux, the
|
2024-07-29 09:52:20 +03:00
|
|
|
# RAX register (x86) or the stack pointer (aarch64) of the guest.
|
2024-03-25 13:45:02 +03:00
|
|
|
#
|
|
|
|
# @arg5: for Windows, fourth argument of the STOP. For x86 Linux, the
|
2024-07-29 09:52:20 +03:00
|
|
|
# stack pointer of the guest.
|
2024-03-25 13:45:02 +03:00
|
|
|
#
|
2017-08-24 22:13:57 +03:00
|
|
|
# Since: 2.9
|
|
|
|
##
|
|
|
|
{'struct': 'GuestPanicInformationHyperV',
|
2023-04-28 13:54:29 +03:00
|
|
|
'data': {'arg1': 'uint64',
|
|
|
|
'arg2': 'uint64',
|
|
|
|
'arg3': 'uint64',
|
|
|
|
'arg4': 'uint64',
|
|
|
|
'arg5': 'uint64'}}
|
s390x/cpu: expose the guest crash information
This patch is the s390 implementation of guest crash information,
similar to commit d187e08dc4 ("i386/cpu: add crash-information QOM
property") and the related commits. We will detect several crash
reasons, with the "disabled wait" being the most important one, since
this is used by all s390 guests as a "panic like" notification.
Demonstrate these ways with examples as follows.
1. crash-information QOM property;
Run qemu with -qmp unix:qmp-sock,server, then use utility "qmp-shell"
to execute "qom-get" command, and might get the result like,
(QEMU) (QEMU) qom-get path=/machine/unattached/device[0] \
property=crash-information
{"return": {"core": 0, "reason": "disabled-wait", "psw-mask": 562956395872256, \
"type": "s390", "psw-addr": 1102832}}
2. GUEST_PANICKED event reporting;
Run qemu with a socket option, and telnet or nc to that,
-chardev socket,id=qmp,port=4444,host=localhost,server \
-mon chardev=qmp,mode=control,pretty=on \
Negotiating the mode by { "execute": "qmp_capabilities" }, and the crash
information will be reported on a guest crash event like,
{
"timestamp": {
"seconds": 1518004739,
"microseconds": 552563
},
"event": "GUEST_PANICKED",
"data": {
"action": "pause",
"info": {
"core": 0,
"psw-addr": 1102832,
"reason": "disabled-wait",
"psw-mask": 562956395872256,
"type": "s390"
}
}
}
3. log;
Run qemu with the parameters: -D <logfile> -d guest_errors, to
specify the logfile and log item. The results might be,
Guest crashed on cpu 0: disabled-wait
PSW: 0x0002000180000000 0x000000000010d3f0
Co-authored-by: Jing Liu <liujbjl@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20180209122543.25755-1-borntraeger@de.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[CH: tweaked qapi comment]
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09 15:25:43 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @S390CrashReason:
|
|
|
|
#
|
|
|
|
# Reason why the CPU is in a crashed state.
|
|
|
|
#
|
|
|
|
# @unknown: no crash reason was set
|
|
|
|
#
|
|
|
|
# @disabled-wait: the CPU has entered a disabled wait state
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @extint-loop: clock comparator or cpu timer interrupt with new PSW
|
|
|
|
# enabled for external interrupts
|
s390x/cpu: expose the guest crash information
This patch is the s390 implementation of guest crash information,
similar to commit d187e08dc4 ("i386/cpu: add crash-information QOM
property") and the related commits. We will detect several crash
reasons, with the "disabled wait" being the most important one, since
this is used by all s390 guests as a "panic like" notification.
Demonstrate these ways with examples as follows.
1. crash-information QOM property;
Run qemu with -qmp unix:qmp-sock,server, then use utility "qmp-shell"
to execute "qom-get" command, and might get the result like,
(QEMU) (QEMU) qom-get path=/machine/unattached/device[0] \
property=crash-information
{"return": {"core": 0, "reason": "disabled-wait", "psw-mask": 562956395872256, \
"type": "s390", "psw-addr": 1102832}}
2. GUEST_PANICKED event reporting;
Run qemu with a socket option, and telnet or nc to that,
-chardev socket,id=qmp,port=4444,host=localhost,server \
-mon chardev=qmp,mode=control,pretty=on \
Negotiating the mode by { "execute": "qmp_capabilities" }, and the crash
information will be reported on a guest crash event like,
{
"timestamp": {
"seconds": 1518004739,
"microseconds": 552563
},
"event": "GUEST_PANICKED",
"data": {
"action": "pause",
"info": {
"core": 0,
"psw-addr": 1102832,
"reason": "disabled-wait",
"psw-mask": 562956395872256,
"type": "s390"
}
}
}
3. log;
Run qemu with the parameters: -D <logfile> -d guest_errors, to
specify the logfile and log item. The results might be,
Guest crashed on cpu 0: disabled-wait
PSW: 0x0002000180000000 0x000000000010d3f0
Co-authored-by: Jing Liu <liujbjl@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20180209122543.25755-1-borntraeger@de.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[CH: tweaked qapi comment]
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09 15:25:43 +03:00
|
|
|
#
|
|
|
|
# @pgmint-loop: program interrupt with BAD new PSW
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @opint-loop: operation exception interrupt with invalid code at the
|
|
|
|
# program interrupt new PSW
|
s390x/cpu: expose the guest crash information
This patch is the s390 implementation of guest crash information,
similar to commit d187e08dc4 ("i386/cpu: add crash-information QOM
property") and the related commits. We will detect several crash
reasons, with the "disabled wait" being the most important one, since
this is used by all s390 guests as a "panic like" notification.
Demonstrate these ways with examples as follows.
1. crash-information QOM property;
Run qemu with -qmp unix:qmp-sock,server, then use utility "qmp-shell"
to execute "qom-get" command, and might get the result like,
(QEMU) (QEMU) qom-get path=/machine/unattached/device[0] \
property=crash-information
{"return": {"core": 0, "reason": "disabled-wait", "psw-mask": 562956395872256, \
"type": "s390", "psw-addr": 1102832}}
2. GUEST_PANICKED event reporting;
Run qemu with a socket option, and telnet or nc to that,
-chardev socket,id=qmp,port=4444,host=localhost,server \
-mon chardev=qmp,mode=control,pretty=on \
Negotiating the mode by { "execute": "qmp_capabilities" }, and the crash
information will be reported on a guest crash event like,
{
"timestamp": {
"seconds": 1518004739,
"microseconds": 552563
},
"event": "GUEST_PANICKED",
"data": {
"action": "pause",
"info": {
"core": 0,
"psw-addr": 1102832,
"reason": "disabled-wait",
"psw-mask": 562956395872256,
"type": "s390"
}
}
}
3. log;
Run qemu with the parameters: -D <logfile> -d guest_errors, to
specify the logfile and log item. The results might be,
Guest crashed on cpu 0: disabled-wait
PSW: 0x0002000180000000 0x000000000010d3f0
Co-authored-by: Jing Liu <liujbjl@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20180209122543.25755-1-borntraeger@de.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[CH: tweaked qapi comment]
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09 15:25:43 +03:00
|
|
|
#
|
|
|
|
# Since: 2.12
|
|
|
|
##
|
|
|
|
{ 'enum': 'S390CrashReason',
|
|
|
|
'data': [ 'unknown',
|
|
|
|
'disabled-wait',
|
|
|
|
'extint-loop',
|
|
|
|
'pgmint-loop',
|
|
|
|
'opint-loop' ] }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @GuestPanicInformationS390:
|
|
|
|
#
|
|
|
|
# S390 specific guest panic information (PSW)
|
|
|
|
#
|
|
|
|
# @core: core id of the CPU that crashed
|
2023-04-28 13:54:29 +03:00
|
|
|
#
|
s390x/cpu: expose the guest crash information
This patch is the s390 implementation of guest crash information,
similar to commit d187e08dc4 ("i386/cpu: add crash-information QOM
property") and the related commits. We will detect several crash
reasons, with the "disabled wait" being the most important one, since
this is used by all s390 guests as a "panic like" notification.
Demonstrate these ways with examples as follows.
1. crash-information QOM property;
Run qemu with -qmp unix:qmp-sock,server, then use utility "qmp-shell"
to execute "qom-get" command, and might get the result like,
(QEMU) (QEMU) qom-get path=/machine/unattached/device[0] \
property=crash-information
{"return": {"core": 0, "reason": "disabled-wait", "psw-mask": 562956395872256, \
"type": "s390", "psw-addr": 1102832}}
2. GUEST_PANICKED event reporting;
Run qemu with a socket option, and telnet or nc to that,
-chardev socket,id=qmp,port=4444,host=localhost,server \
-mon chardev=qmp,mode=control,pretty=on \
Negotiating the mode by { "execute": "qmp_capabilities" }, and the crash
information will be reported on a guest crash event like,
{
"timestamp": {
"seconds": 1518004739,
"microseconds": 552563
},
"event": "GUEST_PANICKED",
"data": {
"action": "pause",
"info": {
"core": 0,
"psw-addr": 1102832,
"reason": "disabled-wait",
"psw-mask": 562956395872256,
"type": "s390"
}
}
}
3. log;
Run qemu with the parameters: -D <logfile> -d guest_errors, to
specify the logfile and log item. The results might be,
Guest crashed on cpu 0: disabled-wait
PSW: 0x0002000180000000 0x000000000010d3f0
Co-authored-by: Jing Liu <liujbjl@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20180209122543.25755-1-borntraeger@de.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[CH: tweaked qapi comment]
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09 15:25:43 +03:00
|
|
|
# @psw-mask: control fields of guest PSW
|
2023-04-28 13:54:29 +03:00
|
|
|
#
|
s390x/cpu: expose the guest crash information
This patch is the s390 implementation of guest crash information,
similar to commit d187e08dc4 ("i386/cpu: add crash-information QOM
property") and the related commits. We will detect several crash
reasons, with the "disabled wait" being the most important one, since
this is used by all s390 guests as a "panic like" notification.
Demonstrate these ways with examples as follows.
1. crash-information QOM property;
Run qemu with -qmp unix:qmp-sock,server, then use utility "qmp-shell"
to execute "qom-get" command, and might get the result like,
(QEMU) (QEMU) qom-get path=/machine/unattached/device[0] \
property=crash-information
{"return": {"core": 0, "reason": "disabled-wait", "psw-mask": 562956395872256, \
"type": "s390", "psw-addr": 1102832}}
2. GUEST_PANICKED event reporting;
Run qemu with a socket option, and telnet or nc to that,
-chardev socket,id=qmp,port=4444,host=localhost,server \
-mon chardev=qmp,mode=control,pretty=on \
Negotiating the mode by { "execute": "qmp_capabilities" }, and the crash
information will be reported on a guest crash event like,
{
"timestamp": {
"seconds": 1518004739,
"microseconds": 552563
},
"event": "GUEST_PANICKED",
"data": {
"action": "pause",
"info": {
"core": 0,
"psw-addr": 1102832,
"reason": "disabled-wait",
"psw-mask": 562956395872256,
"type": "s390"
}
}
}
3. log;
Run qemu with the parameters: -D <logfile> -d guest_errors, to
specify the logfile and log item. The results might be,
Guest crashed on cpu 0: disabled-wait
PSW: 0x0002000180000000 0x000000000010d3f0
Co-authored-by: Jing Liu <liujbjl@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20180209122543.25755-1-borntraeger@de.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[CH: tweaked qapi comment]
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09 15:25:43 +03:00
|
|
|
# @psw-addr: guest instruction address
|
2023-04-28 13:54:29 +03:00
|
|
|
#
|
s390x/cpu: expose the guest crash information
This patch is the s390 implementation of guest crash information,
similar to commit d187e08dc4 ("i386/cpu: add crash-information QOM
property") and the related commits. We will detect several crash
reasons, with the "disabled wait" being the most important one, since
this is used by all s390 guests as a "panic like" notification.
Demonstrate these ways with examples as follows.
1. crash-information QOM property;
Run qemu with -qmp unix:qmp-sock,server, then use utility "qmp-shell"
to execute "qom-get" command, and might get the result like,
(QEMU) (QEMU) qom-get path=/machine/unattached/device[0] \
property=crash-information
{"return": {"core": 0, "reason": "disabled-wait", "psw-mask": 562956395872256, \
"type": "s390", "psw-addr": 1102832}}
2. GUEST_PANICKED event reporting;
Run qemu with a socket option, and telnet or nc to that,
-chardev socket,id=qmp,port=4444,host=localhost,server \
-mon chardev=qmp,mode=control,pretty=on \
Negotiating the mode by { "execute": "qmp_capabilities" }, and the crash
information will be reported on a guest crash event like,
{
"timestamp": {
"seconds": 1518004739,
"microseconds": 552563
},
"event": "GUEST_PANICKED",
"data": {
"action": "pause",
"info": {
"core": 0,
"psw-addr": 1102832,
"reason": "disabled-wait",
"psw-mask": 562956395872256,
"type": "s390"
}
}
}
3. log;
Run qemu with the parameters: -D <logfile> -d guest_errors, to
specify the logfile and log item. The results might be,
Guest crashed on cpu 0: disabled-wait
PSW: 0x0002000180000000 0x000000000010d3f0
Co-authored-by: Jing Liu <liujbjl@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20180209122543.25755-1-borntraeger@de.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[CH: tweaked qapi comment]
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09 15:25:43 +03:00
|
|
|
# @reason: guest crash reason
|
|
|
|
#
|
|
|
|
# Since: 2.12
|
|
|
|
##
|
|
|
|
{'struct': 'GuestPanicInformationS390',
|
2023-04-28 13:54:29 +03:00
|
|
|
'data': {'core': 'uint32',
|
|
|
|
'psw-mask': 'uint64',
|
|
|
|
'psw-addr': 'uint64',
|
|
|
|
'reason': 'S390CrashReason'}}
|
2020-09-30 13:04:39 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @MEMORY_FAILURE:
|
|
|
|
#
|
|
|
|
# Emitted when a memory failure occurs on host side.
|
|
|
|
#
|
|
|
|
# @recipient: recipient is defined as @MemoryFailureRecipient.
|
|
|
|
#
|
2024-03-22 17:09:07 +03:00
|
|
|
# @action: action that has been taken.
|
2020-09-30 13:04:39 +03:00
|
|
|
#
|
2024-03-22 17:09:07 +03:00
|
|
|
# @flags: flags for MemoryFailureAction.
|
2020-09-30 13:04:39 +03:00
|
|
|
#
|
|
|
|
# Since: 5.2
|
|
|
|
#
|
2024-07-17 05:13:08 +03:00
|
|
|
# .. qmp-example::
|
2020-09-30 13:04:39 +03:00
|
|
|
#
|
2024-02-16 17:58:34 +03:00
|
|
|
# <- { "event": "MEMORY_FAILURE",
|
|
|
|
# "data": { "recipient": "hypervisor",
|
|
|
|
# "action": "fatal",
|
|
|
|
# "flags": { "action-required": false,
|
|
|
|
# "recursive": false } },
|
|
|
|
# "timestamp": { "seconds": 1267061043, "microseconds": 959568 } }
|
2020-09-30 13:04:39 +03:00
|
|
|
##
|
|
|
|
{ 'event': 'MEMORY_FAILURE',
|
|
|
|
'data': { 'recipient': 'MemoryFailureRecipient',
|
|
|
|
'action': 'MemoryFailureAction',
|
|
|
|
'flags': 'MemoryFailureFlags'} }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @MemoryFailureRecipient:
|
|
|
|
#
|
|
|
|
# Hardware memory failure occurs, handled by recipient.
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @hypervisor: memory failure at QEMU process address space. (none
|
|
|
|
# guest memory, but used by QEMU itself).
|
2020-09-30 13:04:39 +03:00
|
|
|
#
|
|
|
|
# @guest: memory failure at guest memory,
|
|
|
|
#
|
|
|
|
# Since: 5.2
|
|
|
|
##
|
|
|
|
{ 'enum': 'MemoryFailureRecipient',
|
|
|
|
'data': [ 'hypervisor',
|
|
|
|
'guest' ] }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @MemoryFailureAction:
|
|
|
|
#
|
|
|
|
# Actions taken by QEMU in response to a hardware memory failure.
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @ignore: the memory failure could be ignored. This will only be the
|
|
|
|
# case for action-optional failures.
|
2020-09-30 13:04:39 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @inject: memory failure occurred in guest memory, the guest enabled
|
|
|
|
# MCE handling mechanism, and QEMU could inject the MCE into the
|
|
|
|
# guest successfully.
|
2020-09-30 13:04:39 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @fatal: the failure is unrecoverable. This occurs for
|
|
|
|
# action-required failures if the recipient is the hypervisor;
|
|
|
|
# QEMU will exit.
|
2020-09-30 13:04:39 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @reset: the failure is unrecoverable but confined to the guest.
|
|
|
|
# This occurs if the recipient is a guest guest which is not ready
|
|
|
|
# to handle memory failures.
|
2020-09-30 13:04:39 +03:00
|
|
|
#
|
|
|
|
# Since: 5.2
|
|
|
|
##
|
|
|
|
{ 'enum': 'MemoryFailureAction',
|
|
|
|
'data': [ 'ignore',
|
|
|
|
'inject',
|
|
|
|
'fatal',
|
|
|
|
'reset' ] }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @MemoryFailureFlags:
|
|
|
|
#
|
|
|
|
# Additional information on memory failures.
|
|
|
|
#
|
|
|
|
# @action-required: whether a memory failure event is action-required
|
2023-04-28 13:54:29 +03:00
|
|
|
# or action-optional (e.g. a failure during memory scrub).
|
2020-09-30 13:04:39 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @recursive: whether the failure occurred while the previous failure
|
|
|
|
# was still in progress.
|
2020-09-30 13:04:39 +03:00
|
|
|
#
|
|
|
|
# Since: 5.2
|
|
|
|
##
|
|
|
|
{ 'struct': 'MemoryFailureFlags',
|
|
|
|
'data': { 'action-required': 'bool',
|
|
|
|
'recursive': 'bool'} }
|
2022-09-29 10:20:14 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @NotifyVmexitOption:
|
|
|
|
#
|
|
|
|
# An enumeration of the options specified when enabling notify VM exit
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @run: enable the feature, do nothing and continue if the notify VM
|
|
|
|
# exit happens.
|
2022-09-29 10:20:14 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @internal-error: enable the feature, raise a internal error if the
|
|
|
|
# notify VM exit happens.
|
2022-09-29 10:20:14 +03:00
|
|
|
#
|
|
|
|
# @disable: disable the feature.
|
|
|
|
#
|
|
|
|
# Since: 7.2
|
|
|
|
##
|
|
|
|
{ 'enum': 'NotifyVmexitOption',
|
2023-04-17 19:40:40 +03:00
|
|
|
'data': [ 'run', 'internal-error', 'disable' ] }
|