Re: what is qemu_system_guest_panicked() for?

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Jul 13, 2026 at 10:57:58AM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> 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 :|