Re: what is qemu_system_guest_panicked() for?

[Markus Armbruster <armbru@redhat.com>]

Daniel P. Berrangé <berrange@redhat.com> writes:

> 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.

There is no hard and fast rule.

If a patch changes behavior, and no one is around to observe it, should
we still treat it as compatibility break?  The pragmatic answer is no.

It's of course hard to be sure about non-observation.  The pragmatic
answer to that is "we use the best available data, and where it is
lacking, reasonably conservative guesses."

How likely is it that the fix breaks something else, and how painful
could such breakage be?  Again, hard to be sure, thus reasonably
conservative guesses.

> 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.

I'm not objecting, I just want the compatibility issues considered.

What are the known observers of GUEST_PANICKED?  How would they be
affected by the change?

What are the use cases for observing GUEST_PANICKED?  How could they be
affected?

Reasonably conservative guesses will do.