From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35138) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X05tT-0006cp-0c for qemu-devel@nongnu.org; Thu, 26 Jun 2014 05:23:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X05tM-0000qj-UB for qemu-devel@nongnu.org; Thu, 26 Jun 2014 05:22:58 -0400 Message-ID: <53ABE66A.600@suse.de> Date: Thu, 26 Jun 2014 11:22:50 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1402574971-26672-2-git-send-email-nikunj@linux.vnet.ibm.com> <53A006A9.90108@suse.de> <871tunc288.fsf@linux.vnet.ibm.com> <53A01006.6080800@suse.de> <87y4wvamb3.fsf@linux.vnet.ibm.com> <53A01220.90009@suse.de> <87vbrzale9.fsf@linux.vnet.ibm.com> <87a991ppv7.fsf@abhimanyu.in.ibm.com> <53AAAC97.6030409@suse.de> <87zjh1ns91.fsf@abhimanyu.in.ibm.com> <53AAB335.1070608@suse.de> <87simsw1ev.fsf@abhimanyu.in.ibm.com> <87egyc2g7k.fsf@abhimanyu.in.ibm.com> In-Reply-To: <87egyc2g7k.fsf@abhimanyu.in.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] ppc: spapr-rtas - implement os-term rtas call List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nikunj A Dadhania Cc: "aik@au1.ibm.com" , Benjamin Herrenschmidt , "qemu-ppc@nongnu.org" , "qemu-devel@nongnu.org" , Anton Blanchard On 26.06.14 11:05, Nikunj A Dadhania wrote: > Alexander Graf writes: > >>> Am 26.06.2014 um 09:55 schrieb Nikunj A Dadhania : >>> >>> Alexander Graf writes: >>> >>>>> On 25.06.14 13:27, Nikunj A Dadhania wrote: >>>>> Alexander Graf 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: > > coredump-restart > coredump-destroy > > 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