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

[Alexander Graf <agraf@suse.de>]

On 26.06.14 11:05, Nikunj A Dadhania wrote:
> Alexander Graf <agraf@suse.de> writes:
>
>>> Am 26.06.2014 um 09:55 schrieb Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>:
>>>
>>> Alexander Graf <agraf@suse.de> writes:
>>>
>>>>> On 25.06.14 13:27, Nikunj A Dadhania wrote:
>>>>> Alexander Graf <agraf@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?

I think that's closer to what Linux expects, yes. But I'd like to have 
an ack on that approach from Ben or Anton.


Alex