[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [PATCH v2] ppc: spapr-rtas - implement os-term rtas call

From: Nikunj A Dadhania
Subject: Re: [Qemu-ppc] [PATCH v2] ppc: spapr-rtas - implement os-term rtas call
Date: Thu, 26 Jun 2014 14:35:51 +0530
User-agent: Notmuch/0.17+27~gae47d61 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-redhat-linux-gnu)

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);

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]