Hanna Czenczek <[email protected]> writes: > This state is similar to io-error, but is not entered on I/O errors but > instead when a request takes longer than a user-defined time (set via > the delay-stop-ns property on a block device, which is not yet available > but will be added by a future patch in this series). > > In contrast to other stop states, this state does not drain block > devices. That is because it is entered only when a request hangs, which > means that draining would be counter-productive. > > Signed-off-by: Hanna Czenczek <[email protected]> > --- > qapi/run-state.json | 7 ++++++- > system/runstate.c | 25 ++++++++++++++++++------- > 2 files changed, 24 insertions(+), 8 deletions(-) > > diff --git a/qapi/run-state.json b/qapi/run-state.json > index 8bbd9884087..cf3f43579de 100644 > --- a/qapi/run-state.json > +++ b/qapi/run-state.json > @@ -53,12 +53,17 @@ > # @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) > +# > +# @io-hang: An I/O operation has been delayed for too long and the > +# device is configured to stop the VM when that happens. In > +# contrast to other paused states, the VM's block devices will not > +# be drained when entering this run state. (since 11.2) > ## > { 'enum': 'RunState', > 'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused', > 'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm', > 'running', 'save-vm', 'shutdown', 'suspended', 'watchdog', > - 'guest-panicked', 'colo' ] } > + 'guest-panicked', 'colo', 'io-hang' ] } > > ## > # @ShutdownCause:
QAPI schema Acked-by: Markus Armbruster <[email protected]>
