From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56241) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S39EO-0003vJ-DI for qemu-devel@nongnu.org; Thu, 01 Mar 2012 11:51:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S39EH-0001I5-EM for qemu-devel@nongnu.org; Thu, 01 Mar 2012 11:51:51 -0500 Received: from mx1.redhat.com ([209.132.183.28]:26638) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S39EH-0001Hk-5f for qemu-devel@nongnu.org; Thu, 01 Mar 2012 11:51:45 -0500 Date: Thu, 1 Mar 2012 13:51:39 -0300 From: Luiz Capitulino Message-ID: <20120301135139.5f2b2a5c@doriath.home> In-Reply-To: <4F4AF316.50400@cn.fujitsu.com> References: <4F4AF1FB.6000903@cn.fujitsu.com> <4F4AF316.50400@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH]qemu: deal with guest paniced event List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang Cc: kvm list , qemu-devel , linux-kernel@vger.kernel.org, Avi Kivity , KAMEZAWA Hiroyuki On Mon, 27 Feb 2012 11:05:58 +0800 Wen Congyang wrote: > When the host knows the guest is paniced, it will set > exit_reason to KVM_EXIT_GUEST_PANIC. So if qemu receive > this exit_reason, we can send a event to tell management > application that the guest is paniced. > > Signed-off-by: Wen Congyang > --- > kvm-all.c | 3 +++ > linux-headers/linux/kvm.h | 1 + > monitor.c | 3 +++ > monitor.h | 1 + > 4 files changed, 8 insertions(+), 0 deletions(-) > > diff --git a/kvm-all.c b/kvm-all.c > index c4babda..ae428ab 100644 > --- a/kvm-all.c > +++ b/kvm-all.c > @@ -1190,6 +1190,9 @@ int kvm_cpu_exec(CPUState *env) > (uint64_t)run->hw.hardware_exit_reason); > ret = -1; > break; > + case KVM_EXIT_GUEST_PANIC: > + monitor_protocol_event(QEVENT_GUEST_PANICED, NULL); > + break; The event alone is not enough, because the mngt app may miss it (eg. the panic happens before the mngt app connected to qemu). A simple way to solve this would be to also add a new RunState called guest-panic and make the transition to it (besides sending the event). A more general way would be to model this after -drive's werror/rerror options, say guest-error=report|ignore|stop. When guest-error=stop, the mngt app will get a STOP event and can check the VM runstate to know if it's guest-panic.