For further backgrou, the key end goal here is that in a QMP client, upon
receipt of the 'RESET' event, we need to reliably& immediately determine
why it occurred. eg, triggered by watchdog, or by guest OS request. There
are actually 3 possible sequences
- WATCHDOG + action=reset, followed by RESET. Assuming no intervening
event can occurr, the client can merely record 'WATCHDOG' and interpret
it when it gets the immediately following 'RESET' event
- RESET, followed by WATCHDOG + action=reset. The client doesn't know
the reason for the RESET and can't wait arbitrarily for WATCHDOG since
there might never be one arriving.
- RESET + source=watchdog. Client directly sees the reason
The second scenario is the one I'd like us to avoid at all costs, since it
will require the client to introduce arbitrary delays in processing events
to determine cause. The first is slightly inconvenient, but doable if we
can assume no intervening events will occur, between WATCHDOG and the
RESET events. The last is obviously simplest for the clients.