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.
