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. 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. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
