On Tue, 15 Dec 2020 at 18:11, Paolo Bonzini <pbonz...@redhat.com> wrote: > > From: Alejandro Jimenez <alejandro.j.jime...@oracle.com> > > The current default action of pausing a guest after a panic event > is received leaves the responsibility to resume guest execution to the > management layer. The reasons for this behavior are discussed here: > https://lore.kernel.org/qemu-devel/52148f88.5000...@redhat.com/ > > However, in instances like the case of older guests (Linux and > Windows) using a pvpanic device but missing support for the > PVPANIC_CRASHLOADED event, and Windows guests using the hv-crash > enlightenment, it is desirable to allow the guests to continue > running after sending a PVPANIC_PANICKED event. This allows such > guests to proceed to capture a crash dump and automatically reboot > without intervention of a management layer. > > Add an option to avoid stopping a VM after a panic event is received, > by passing: > > -action panic=none > > in the command line arguments, or during runtime by using an upcoming > QMP command.
Hi. This commit message doesn't say it's changing the default action, but the change does: > @@ -3899,6 +3899,8 @@ DEF("action", HAS_ARG, QEMU_OPTION_action, > " action when guest reboots [default=none]\n" > "-action shutdown=poweroff|pause\n" > " action when guest shuts down [default=poweroff]\n" > + "-action panic=poweroff|pause|none\n" > + " action when guest panics [default=poweroff]\n" > "-action watchdog=reset|shutdown|poweroff|inject-nmi|pause|debug|none\n" > " action when watchdog fires [default=reset]\n", > QEMU_ARCH_ALL) > RebootAction reboot_action = REBOOT_ACTION_NONE; > ShutdownAction shutdown_action = SHUTDOWN_ACTION_POWEROFF; > +PanicAction panic_action = PANIC_ACTION_POWEROFF; We used to default to 'pause' and now we default to 'poweroff'. We noticed this because it broke an in-flight test case for the pvpanic-pci device from Mihai (which was expecting to see the device in 'pause' state and found it was now in 'poweroff'). Test cases aren't very exciting, but was it really intentional to change the default behaviour? It's part of the user-facing surface of QEMU, so if we did intend a default change that ought really to be more clearly stated (and noted in the Changelog) I think. thanks -- PMM