On Mon, Jul 13 2026, Daniel P. Berrangé <[email protected]> wrote:
> On Mon, Jul 13, 2026 at 10:57:58AM +0200, Markus Armbruster wrote: >> Daniel P. Berrangé <[email protected]> writes: >> >> > On Fri, Jul 10, 2026 at 05:02:53PM +0100, Peter Maydell wrote: >> >> [...] >> >> >> So I guess my question is, is it OK to mash these two categories of >> >> "we can't keep running the VM" together, or should we define a new >> >> one for the "unrecoverable guest error" case, or do we already have >> >> some better thing to do that I missed? >> > >> > IMHO we should NOT be abusing "panicked" for cases which are >> > not guest OS panics. >> >> Point. >> >> > Adding new QMP events is cheap and we should do so. >> >> Changing the event sent on a certain situation is technically a >> compatibility break. Would it matter here? > > What wins "compat break" or "bug fix" ? A strict POV prevents almost > any bug fixes, if you want to remain bug-for-bug compatible with > old QEMU. > > With my "management app" hat on, I want QEMU to stop sending panic > events for things that are not panics, as that is triggering incorrect > actions / admin activities. ie on a panic, I'm going to take a guest > memory dump and try to analyse what is broken in the guest kernel. That would argue for e.g. a guest exception loop being a "panic" as well, as the admin may want to debug that. > > The QAPI spec says: > > ## > # @GUEST_PANICKED: > # > # Emitted when guest OS panic is detected > > > and > > ## > # @RunState: > # > # An enumeration of VM run states. > # > .. > # @guest-panicked: guest has been panicked as a result of guest OS > # panic > > > I don't think "machine check exception" or "unknown VM exit" > can be said to match either of those docs, and thus fixing > compliance should trump bug-for-bug compatibility IMHO. I'm wondering whether we first need to agree upon a common definition of what a "guest OS panic" is. "The Linux kernel ran into a panic() statement" clearly is; is "the guest OS put itself into a state of which the only way out is a reboot" a "guest OS panic" as well, or only in some cases?
