Alexander Graf <address@hidden> writes:
Am 26.06.2014 um 09:55 schrieb Nikunj A Dadhania <address@hidden>:
Alexander Graf <address@hidden> writes:
On 25.06.14 13:27, Nikunj A Dadhania wrote:
Alexander Graf <address@hidden> 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?