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 03:57:25PM +0200, Markus Armbruster wrote:
>> Daniel P. Berrangé <berrange@redhat.com> writes:

[...]

>> > When libvirt see a GUEST_PANICKED, it will transition the state to
>> > "CRASHED" and assign a reason of "PANICKED" as the trigger / cause.
>> >
>> > Then depending on the guest XML config for <on_crash> it will do one
>> > of
>> >
>> >  * Take a core dump of QEMU
>> >  * Terminate QEMU
>> >  * Restart QEMU
>> >  * Take a core dump of QEMU and restart
>> >  * Leave it in crashed state (to allow a debugger to attach)
>> >
>> >
>> > The "machine check" and "unknown VM exit" scenarios, would still map
>> > to libvirt's "CRASHED" state, but we would want to assign distinct
>> > "cause" for each of them.
>> 
>> Say we add event GUEST_MACHINE_CHECK, then send it instead of
>> GUEST_PANICKED on a machine check.
>> 
>> With an updated version of libvirt, this changes exactly the "cause"
>> recorded for a machine check in the "CRASHED" state.  This change is
>> desirable.
>> 
>> Older versions of libvirt ignore the unknown GUEST_MACHINE_CHECK event.
>> They therefore no longer take the <on_crash> action.  This is
>> undesirable, I'm afraid.  Is it?
>> 
>> An orderly transition could look like this:
>> 
>> 1. Add a new event for each distinct cause, and emit the appropriate
>>    event in addition to GUEST_PANICKED.
>> 
>> 2. Deprecate GUEST_PANICKED.
>> 
>> 3. Remove GUEST_PANICKED after a suitable grace period.
>
> Another option is to accept  "GUEST_PANICKED" as a sub-optimal name
> forever and add a "source" field to the event to explain what actually
> triggered it, where "source" can be  "guest-os", "machine-check", ...
> etc...

Yes, that's a compatible extension.

> Which would probably be better compatible with libvirt too
>
> With regards,
> Daniel