+ shivang
On 13/07/26 19:06, Fabiano Rosas wrote:
Peter Maydell <[email protected]> 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
