what is qemu_system_guest_panicked() for?

what is qemu_system_guest_panicked() for?

[Peter Maydell]

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

At least one or two of the above have comments to the effect that
they don't want to use e.g. cpu_abort() because they want to give
the user the ability to examine the VM after this unrecoverable
guest error, rather than just exiting QEMU.

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?

In particular, "do nothing" might be a reasonable response for the
user to configure to a guest panic notification, since the guest will
presumably stick the vcpu into a do-nothing loop, but "do nothing"
doesn't make sense for "unrecoverable guest error" because we'll
probably then sit in QEMU in a tight loop retrying whatever it
was that failed.

If we had some kind of qemu_system_unrecoverable_guest_error() then
we could maybe convert some uses of cpu_abort() over to that (though
uses of cpu_abort() are a very mixed bunch, some of which should be
LOG_UNIMP or LOG_GUEST_ERROR and continue and some of which should
be straightforward assertions, as well as some which might be this
new exit case).

(This query was prompted by a patch for arm whpx which adds a new
qemu_system_guest_panicked() call for an unhandled VM exit situation.)

thanks
-- PMM

Re: what is qemu_system_guest_panicked() for?

[Harsh Prateek Bora]

+ folks who might have an opinion from PPC RAS perspective as MCE, 
checkstop related.

On 10/07/26 9:32 pm, Peter Maydell 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
>   - 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

I liked the suggestion of qemu_system_unrecoverable_guest_error() but 
let's hear from others as well.

regards,
Harsh

>     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
>   - s390 unmanageable_intercept(): again not sure, think this is where
>     the guest has gone off the rails and we can't keep running
> 
> At least one or two of the above have comments to the effect that
> they don't want to use e.g. cpu_abort() because they want to give
> the user the ability to examine the VM after this unrecoverable
> guest error, rather than just exiting QEMU.
> 
> 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?
> 
> In particular, "do nothing" might be a reasonable response for the
> user to configure to a guest panic notification, since the guest will
> presumably stick the vcpu into a do-nothing loop, but "do nothing"
> doesn't make sense for "unrecoverable guest error" because we'll
> probably then sit in QEMU in a tight loop retrying whatever it
> was that failed.
> 
> If we had some kind of qemu_system_unrecoverable_guest_error() then
> we could maybe convert some uses of cpu_abort() over to that (though
> uses of cpu_abort() are a very mixed bunch, some of which should be
> LOG_UNIMP or LOG_GUEST_ERROR and continue and some of which should
> be straightforward assertions, as well as some which might be this
> new exit case).
> 
> (This query was prompted by a patch for arm whpx which adds a new
> qemu_system_guest_panicked() call for an unhandled VM exit situation.)
> 
> thanks
> -- PMM

Re: what is qemu_system_guest_panicked() for?

[Daniel P. Berrangé]

On Fri, Jul 10, 2026 at 05:02:53PM +0100, Peter Maydell 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
>  - 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
>  - s390 unmanageable_intercept(): again not sure, think this is where
>    the guest has gone off the rails and we can't keep running
> 
> At least one or two of the above have comments to the effect that
> they don't want to use e.g. cpu_abort() because they want to give
> the user the ability to examine the VM after this unrecoverable
> guest error, rather than just exiting QEMU.
> 
> 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.

Adding new QMP events is cheap and we should do so. We need
at least a "MCE"  event.

IMHO the "unknown / unexpected" VM exits likely deserve a
different event again.

> 
> In particular, "do nothing" might be a reasonable response for the
> user to configure to a guest panic notification, since the guest will
> presumably stick the vcpu into a do-nothing loop, but "do nothing"
> doesn't make sense for "unrecoverable guest error" because we'll
> probably then sit in QEMU in a tight loop retrying whatever it
> was that failed.
> 
> If we had some kind of qemu_system_unrecoverable_guest_error() then
> we could maybe convert some uses of cpu_abort() over to that (though
> uses of cpu_abort() are a very mixed bunch, some of which should be
> LOG_UNIMP or LOG_GUEST_ERROR and continue and some of which should
> be straightforward assertions, as well as some which might be this
> new exit case).
> 
> (This query was prompted by a patch for arm whpx which adds a new
> qemu_system_guest_panicked() call for an unhandled VM exit situation.)
> 
> thanks
> -- PMM
> 

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

Re: what is qemu_system_guest_panicked() for?

[Markus Armbruster]

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?

>                                                     We need
> at least a "MCE"  event.
>
> IMHO the "unknown / unexpected" VM exits likely deserve a
> different event again.

[...]

Re: what is qemu_system_guest_panicked() for?

[Daniel P. Berrangé]

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

Re: what is qemu_system_guest_panicked() for?

[Cornelia Huck]

On Mon, Jul 13 2026, Daniel P. Berrangé <berrange@redhat.com> wrote:

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

That would argue for e.g. a guest exception loop being a "panic" as
well, as the admin may want to debug that.

>
> 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 wondering whether we first need to agree upon a common definition of
what a "guest OS panic" is. "The Linux kernel ran into a panic()
statement" clearly is; is "the guest OS put itself into a state of which
the only way out is a reboot" a "guest OS panic" as well, or only in
some cases?

Re: what is qemu_system_guest_panicked() for?

[Markus Armbruster]

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.

Re: what is qemu_system_guest_panicked() for?

[Daniel P. Berrangé]

On Mon, Jul 13, 2026 at 01:43:46PM +0200, Markus Armbruster wrote:
> 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.

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.

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

Re: what is qemu_system_guest_panicked() for?

[Markus Armbruster]

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

> On Mon, Jul 13, 2026 at 01:43:46PM +0200, Markus Armbruster wrote:
>> 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.
>
> 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.

Re: what is qemu_system_guest_panicked() for?

[Daniel P. Berrangé]

On Mon, Jul 13, 2026 at 03:57:25PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > On Mon, Jul 13, 2026 at 01:43:46PM +0200, Markus Armbruster wrote:
> >> 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.
> >
> > 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...

Which would probably be better compatible with libvirt too

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

Re: what is qemu_system_guest_panicked() for?

[Markus Armbruster]

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

Re: what is qemu_system_guest_panicked() for?

[Peter Maydell]

On Mon, 13 Jul 2026 at 09:40, Daniel P. Berrangé <berrange@redhat.com> wrote:
> IMHO we should NOT be abusing "panicked" for cases which are
> not guest OS panics.
>
> Adding new QMP events is cheap and we should do so. We need
> at least a "MCE"  event.
>
> IMHO the "unknown / unexpected" VM exits likely deserve a
> different event again.

So what classifications would we like here?

"panic" == "the guest OS told us it has crashed" is pretty clear.

What is "machine check exception" intended to mean? Is that for
"the host hardware has a problem and we don't have a way to
tell the guest about it" ?

"unknown/unexpected VM exit" feels to me like a subset of a
larger category: "something happened that QEMU can't handle and
we can't keep running the guest". That "something" could be any of:

 - KVM/another accelerator told us about a problem
 - QEMU doesn't implement something and the missing functionality
   is serious enough that we can't continue guest execution
   (possible example: on Arm, an attempt to execute from an MMIO
   region: we can't do that under an accelerator, and we can't
   really continue the VM. We could feed the guest an exception,
   but it won't be expecting that.)
 - the guest did something that put the VM into a state where
   we can't continue (e.g. s390 going into an exception loop,
   or Arm M-profile Lockup state). On real hardware this would
   typically result in the system sitting there doing nothing
   useful forever. In QEMU we could emulate "do nothing" but
   it's probably more helpful to the user to stop the VM.

Categories 2 and 3 you can get without KVM, so "VM exit" doesn't
really apply there.

Do we care about splitting those up? Is there a good name for
these kinds of failure?

thanks
-- PMM

Re: what is qemu_system_guest_panicked() for?

[Cornelia Huck]

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.

Re: what is qemu_system_guest_panicked() for?

[Christian Borntraeger]

Am 13.07.26 um 12:22 schrieb Cornelia Huck:
>> Cases which are not:
[...]
>>   - 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.
Right. I think having both cases in the same bucket makes sense.

Re: what is qemu_system_guest_panicked() for?

[Fabiano Rosas]

Peter Maydell <peter.maydell@linaro.org> writes:

> (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
>  - the pvpanic device
>  - the spapr ibm,os-term RTAS call

I think I remember this one is arbitrary and the spec doesn't really
interprets this as an error state of any sort. It's just that this is
the way it has been used.

I had to comment that qemu_system_guest_panicked line a few times when
experimenting with using os-term to do a clean termination _from_ the
guest code.

PPC folks, please confirm, it's been years since I looked at this.

>  - 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
>  - s390 unmanageable_intercept(): again not sure, think this is where
>    the guest has gone off the rails and we can't keep running
>
> At least one or two of the above have comments to the effect that
> they don't want to use e.g. cpu_abort() because they want to give
> the user the ability to examine the VM after this unrecoverable
> guest error, rather than just exiting QEMU.
>
> 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?
>
> In particular, "do nothing" might be a reasonable response for the
> user to configure to a guest panic notification, since the guest will
> presumably stick the vcpu into a do-nothing loop, but "do nothing"
> doesn't make sense for "unrecoverable guest error" because we'll
> probably then sit in QEMU in a tight loop retrying whatever it
> was that failed.
>
> If we had some kind of qemu_system_unrecoverable_guest_error() then
> we could maybe convert some uses of cpu_abort() over to that (though
> uses of cpu_abort() are a very mixed bunch, some of which should be
> LOG_UNIMP or LOG_GUEST_ERROR and continue and some of which should
> be straightforward assertions, as well as some which might be this
> new exit case).
>
> (This query was prompted by a patch for arm whpx which adds a new
> qemu_system_guest_panicked() call for an unhandled VM exit situation.)
>
> thanks
> -- PMM

Re: what is qemu_system_guest_panicked() for?

[Aditya Gupta]

+ shivang


On 13/07/26 19:06, Fabiano Rosas wrote:

> Peter Maydell <peter.maydell@linaro.org> writes:
>
>> (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
>>   - the pvpanic device
>>   - the spapr ibm,os-term RTAS call
> I think I remember this one is arbitrary and the spec doesn't really
> interprets this as an error state of any sort. It's just that this is
> the way it has been used.
>
> I had to comment that qemu_system_guest_panicked line a few times when
> experimenting with using os-term to do a clean termination _from_ the
> guest code.
>
> PPC folks, please confirm, it's been years since I looked at this.
True. The way the spec mentions it seems the OS can get control back after
execution of ibm,os-term.

This difference is noticeable with `panic=15`. On an LPAR, this would 
print the
following line and do a reboot after a timeout of 15s (this happens in linux
after it has done the os-term call):

     [  338.186072] Rebooting in 15 seconds..

But on QEMU, this isn't printed, and the machine powers down:

     qemu-system-ppc64: OS terminated:

Maybe worth taking a look. Didn't notice this earlier, thanks Fabiano !

- Aditya G

Re: what is qemu_system_guest_panicked() for?

[Shivang Upadhyay]

On Tue, 2026-07-14 at 15:54 +0530, Aditya Gupta wrote:
> > guest code.
> > 
> > PPC folks, please confirm, it's been years since I looked at this.
> True. The way the spec mentions it seems the OS can get control back
> after
> execution of ibm,os-term.
> 
> This difference is noticeable with `panic=15`. On an LPAR, this would
> print the
> following line and do a reboot after a timeout of 15s (this happens
> in linux
> after it has done the os-term call):
> 
>      [  338.186072] Rebooting in 15 seconds..
> 
> But on QEMU, this isn't printed, and the machine powers down:
> 
>      qemu-system-ppc64: OS terminated:
> 
> Maybe worth taking a look. Didn't notice this earlier, thanks Fabiano
> !
> 

Hi Aditya Fabiano,
 As we register the rtas(os-term) as the panic handler for spapr in
linux, I think we expect the machine to be shut-down properly and not
handle any of the work. I am not sure how else would we implement this
function in qemu without using `qemu_system_guest_panicked`. I mean,
the name conveys, the guest has "paniced".

But then again as per PAPR, we should expected limited number of rtas
calls from the OS (the following list).
- nvram-fetch
- nvram-store
- display-character
- power-off
- ibm,power-off-ups
- system-reboot
- check-exception

PAPR reffers to host as "live-halt" after it has called os-term. Not
very sure on the meaning of this.

Maybe other platforms then linux will rely on this? As Fabiano
suggested he found some case where he needed to comment it out, That
would be interesting scenario to explore.

Regards
~Shivang.

Re: what is qemu_system_guest_panicked() for?

[Fabiano Rosas]

Shivang Upadhyay <shivangu@linux.ibm.com> writes:

> On Tue, 2026-07-14 at 15:54 +0530, Aditya Gupta wrote:
>> > guest code.
>> > 
>> > PPC folks, please confirm, it's been years since I looked at this.
>> True. The way the spec mentions it seems the OS can get control back
>> after
>> execution of ibm,os-term.
>> 
>> This difference is noticeable with `panic=15`. On an LPAR, this would
>> print the
>> following line and do a reboot after a timeout of 15s (this happens
>> in linux
>> after it has done the os-term call):
>> 
>>      [  338.186072] Rebooting in 15 seconds..
>> 
>> But on QEMU, this isn't printed, and the machine powers down:
>> 
>>      qemu-system-ppc64: OS terminated:
>> 
>> Maybe worth taking a look. Didn't notice this earlier, thanks Fabiano
>> !
>> 
>
> Hi Aditya Fabiano,
>  As we register the rtas(os-term) as the panic handler for spapr in
> linux, I think we expect the machine to be shut-down properly and not
> handle any of the work. I am not sure how else would we implement this
> function in qemu without using `qemu_system_guest_panicked`. I mean,
> the name conveys, the guest has "paniced".
>
> But then again as per PAPR, we should expected limited number of rtas
> calls from the OS (the following list).
> - nvram-fetch
> - nvram-store
> - display-character
> - power-off
> - ibm,power-off-ups
> - system-reboot
> - check-exception
>
> PAPR reffers to host as "live-halt" after it has called os-term. Not
> very sure on the meaning of this.
>
> Maybe other platforms then linux will rely on this? As Fabiano
> suggested he found some case where he needed to comment it out, That
> would be interesting scenario to explore.
>

To be clear: I don't know of anything that currently depends on a more
rigorous behavior of os-term.

If Linux, and probably other major OSes, use os-term to relay a panic
state to the hypervisor, this is fine. For the purposes of Peter's
question I think we can leave it at that.

---

PS:
The use-case I had in the past was related to this test suite:
https://github.com/legoater/pnv-test. I was looking for a way to do
clean termination of a vm from the guest OS while conveying the test
output in the message.

E.g:

$ cat slof.s
li      3,0
ori     3,3,61440       # H_RTAS
li      4,argbuf
.long 0x44000022
b .

argbuf:
.long 0x201f    # ibm,os-term
.long 0x65786974 # "exit"
.long 0 
.long . -8

$ ./qemu-system-ppc64 -bios slof.bin -d guest_errors
qemu: OS terminated: exit
Guest crashed

Re: what is qemu_system_guest_panicked() for?

[Fabiano Rosas]

Peter Maydell <peter.maydell@linaro.org> writes:

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

1) The Checkstop state is the state the (modern) architecture prescribes
the machine transitions to when: a) machine check happens but machine
check exceptions are disabled or b) hard-to-recover storage errors. On
older user manuals I also see occurrences of checkstop when (a) above
happens and a "debug bit" is also set.

  603 UM:
  "[cpu] must terminate operation by internally gating off all clocks, and
  release all outputs to the high impedance state"
  
  750cx UM:
  "When a processor is in checkstop state, instruction processing is
  suspended and generally cannot resume without the processor being
  reset."

2) There's also a QEMU-specific usage when handling the processor
implementation specific 'attn' instruction. The instruction is
originally designed to allow the OS to poke the hardware or service
processor for debugging purposes. I think in practice this ends up being
very similar (or possibly the same) as checkstop so QEMU does the same
as the previous case.

>  - s390_handle_wait(): not sure exactly what this is
>  - s390 unmanageable_intercept(): again not sure, think this is where
>    the guest has gone off the rails and we can't keep running
>
> At least one or two of the above have comments to the effect that
> they don't want to use e.g. cpu_abort() because they want to give
> the user the ability to examine the VM after this unrecoverable
> guest error, rather than just exiting QEMU.
>
> 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?
>
> In particular, "do nothing" might be a reasonable response for the
> user to configure to a guest panic notification, since the guest will
> presumably stick the vcpu into a do-nothing loop, but "do nothing"
> doesn't make sense for "unrecoverable guest error" because we'll
> probably then sit in QEMU in a tight loop retrying whatever it
> was that failed.
>
> If we had some kind of qemu_system_unrecoverable_guest_error() then
> we could maybe convert some uses of cpu_abort() over to that (though
> uses of cpu_abort() are a very mixed bunch, some of which should be
> LOG_UNIMP or LOG_GUEST_ERROR and continue and some of which should
> be straightforward assertions, as well as some which might be this
> new exit case).
>
> (This query was prompted by a patch for arm whpx which adds a new
> qemu_system_guest_panicked() call for an unhandled VM exit situation.)
>
> thanks
> -- PMM

Re: what is qemu_system_guest_panicked() for?

[Peter Maydell]

On Mon, 13 Jul 2026 at 15:49, Fabiano Rosas <farosas@suse.de> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
> >  - ppc TCG, in powerpc_checkstop(), for a machine check exception I think
>
> 1) The Checkstop state is the state the (modern) architecture prescribes
> the machine transitions to when: a) machine check happens but machine
> check exceptions are disabled or b) hard-to-recover storage errors. On
> older user manuals I also see occurrences of checkstop when (a) above
> happens and a "debug bit" is also set.
>
>   603 UM:
>   "[cpu] must terminate operation by internally gating off all clocks, and
>   release all outputs to the high impedance state"
>
>   750cx UM:
>   "When a processor is in checkstop state, instruction processing is
>   suspended and generally cannot resume without the processor being
>   reset."

Thanks. So since this is in TCG, is this for the case "we emulated
the CPU ending up in a checkstop situation", rather than "the real
host hardware is broken" ? Can the guest deliberately provoke real
hardware into this state, or is it only something you can get into
when the h/w is broken ?

-- PMM

Re: what is qemu_system_guest_panicked() for?

[Fabiano Rosas]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Mon, 13 Jul 2026 at 15:49, Fabiano Rosas <farosas@suse.de> wrote:
>>
>> Peter Maydell <peter.maydell@linaro.org> writes:
>> >  - ppc TCG, in powerpc_checkstop(), for a machine check exception I think
>>
>> 1) The Checkstop state is the state the (modern) architecture prescribes
>> the machine transitions to when: a) machine check happens but machine
>> check exceptions are disabled or b) hard-to-recover storage errors. On
>> older user manuals I also see occurrences of checkstop when (a) above
>> happens and a "debug bit" is also set.
>>
>>   603 UM:
>>   "[cpu] must terminate operation by internally gating off all clocks, and
>>   release all outputs to the high impedance state"
>>
>>   750cx UM:
>>   "When a processor is in checkstop state, instruction processing is
>>   suspended and generally cannot resume without the processor being
>>   reset."
>
> Thanks. So since this is in TCG, is this for the case "we emulated
> the CPU ending up in a checkstop situation", rather than "the real
> host hardware is broken" ? Can the guest deliberately provoke real
> hardware into this state, or is it only something you can get into
> when the h/w is broken ?
>

The former, checkstop emulation. The guest cannot cause real hardware to
be in this state, this is the cosmic rays kind of problem.