Re: what is qemu_system_guest_panicked() for?

[Cornelia Huck <cohuck@redhat.com>]

On Fri, Jul 10 2026, Peter Maydell <peter.maydell@linaro.org> wrote:

> (cc list is a random mix of maintainers of code that calls this
> function, Paolo as "main loop maintainer" and a few others who
> I thought might have an opinion.)
>
> We have a qemu_system_guest_panicked() function which causes QEMU
> to report this to the user and do one of a couple of possible options
> (shutdown, pause the VM, do nothing). This seems mostly intended for
> "the guest OS told us by some mechanism that it just panicked". But
> we use it more widely than that...
>
> Cases which are "the guest told us about a panic":
>  - accel/kvm/kvm-all.c handling of the KVM_EXIT_SYSTEM_EVENT SEV_TERM
>    and CRASH subtypes

These two events seem to be x86 only.

>  - the pvpanic device
>  - the spapr ibm,os-term RTAS call
>  - x86 kvm: tdx_panicked_on_fatal_error()
>  - x86 xen: the SHUTDOWN_crash shutdown subtype
>
> Cases which are not:
>  - hw/spapr/rtas.c: if the FDT has no RTAS address during system reset
>  - hw/spapr/spapr_events.c: if we wanted to deliver a machine check
>    exception to the guest but the FDT has no RTAS address
>  - hw/spapr/spapr_events.c: if we want to deliver a machine check
>    but the guest is still dealing with a previous machine check
>  - arm whpx, if we get an unknown/unexpected exit code trying to run the VM
>  - x86 nvmm, for an unknown/unexpected VM exit code
>  - ppc TCG, in powerpc_checkstop(), for a machine check exception I think
>  - s390_handle_wait(): not sure exactly what this is

Loading a "disabled wait PSW" (waiting for interrupts with no interrupts
enabled) is basically the way for an OS to "panic". (The "special wait
PSW" is for signifying that a cpu has been shut down.) IOW, this is
indeed the "panic" case for s390x.

>  - s390 unmanageable_intercept(): again not sure, think this is where
>    the guest has gone off the rails and we can't keep running

It's basically "the handling code for an exception immediately leads to
the same exception", the cpu has gone into a loop and can't get out of
it again. Not sure if that should be getting some different handling.