Alexander Graf <ag...@suse.de> writes: >> Am 26.06.2014 um 09:55 schrieb Nikunj A Dadhania <nik...@linux.vnet.ibm.com>: >> >> Alexander Graf <ag...@suse.de> writes: >> >>>> On 25.06.14 13:27, Nikunj A Dadhania wrote: >>>> Alexander Graf <ag...@suse.de> writes: >>>> >>>> Let me put down my understanding: >>>> >>>> There are two possible way to handle kernel panic: >>>> 1) Kdump service running in guest - already working >>>> 2) Pass the kernel panic information to hypervisor - not there in Qemu >>>> pseries >>>> >>>> So without kdump service running, if linux kernel hits a panic, its going >>>> to check os-term and extended-os-term, only then its going to call >>>> os-term. >>> >>> It's checking both for a reason. Find that reason. >> >> Here is what I figured out from PAPR: >> >> rtas ibm,os-term, does not gaurantee a return back to the guest cpu. >> >> If ibm,extended-os-term property is set rtas call return will always >> occur. > > With your patch it doesn't occur.
Hmm, you are right. + monitor_protocol_event(QEVENT_GUEST_PANICKED, data); + qobject_decref(data); + vm_stop(RUN_STATE_GUEST_PANICKED); So the issue here is using vm_stop. So if I do not do this I will be returning back to the guest. I was trying to enable: <on_crash> coredump-restart </on_crash> <on_crash> coredump-destroy </on_crash> in libvirt. But anyways, when libvirt receives these event, it will either destroy or restart the guest. So if I remove the vm_stop, there will be a return to the guest. And depending on the libvirt domain config a restart/destroy will take effect. Does this look ok? Regards Nikunj
