Peter Maydell <peter.mayd...@linaro.org> writes: > Hi; one of the "bitesized tasks" we have listed is to convert > watchdog timers which directly call qemu_system_reset_request() on > watchdog timeout to call watchdog_perform_action() instead. This > means they honour the QMP commands that let the user specifiy > the behaviour on watchdog expiry: > https://www.qemu.org/docs/master/interop/qemu-qmp-ref.html#qapidoc-141 > https://www.qemu.org/docs/master/interop/qemu-qmp-ref.html#qapidoc-129 > (choices include reset, power off the system, do nothing, etc). > > There are only a few remaining watchdogs that don't use the > watchdog_perform_action() function. In most cases the change > is obvious and easy: just make them do that instead of calling > qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET). > > However, the hw/watchdog/spapr_watchdog.c case is trickier. As > far as I can tell from the sources, this is a watchdog set up via > a hypercall, and the guest makes a choice of "power off, restart, > or dump and restart" for its on-expiry action. > > What should this watchdog's interaction with the watchdog-set-action > QMP command be? If the user says "do X" and the guest says "do Y", > which do we do? (With the current code, we always honour what > the guest asks for and ignore what the user asks for.)
Gut reaction: when the user says "do X", the guest should not get a say. But one of the values of X could be "whatever the guest says". > (The bitesized task for watchdog_perform_action() is > https://gitlab.com/qemu-project/qemu/-/issues/2124 . For the > purposes of this email thread I'm only after a concrete decision > about what we think the right thing is, not for any code. Then > I can write that up in the bug for potential new contributors.) > > thanks > -- PMM
