From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jan Kiszka <jan.kiszka@siemens.com>
Subject: Re: [PATCH 0/2] Introduce panic hypercall
Date: Mon, 20 Jun 2011 17:59:19 +0200
Message-ID: <4DFF6E57.7040109@siemens.com>
References: <1308577094-17551-1-git-send-email-gollub@b1-systems.de> <4DFF67CB.3060807@redhat.com> <20110620153825.GH13042@redhat.com> <4DFF6B20.7090107@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "Daniel P. Berrange" <berrange@redhat.com>,
	Daniel Gollub <gollub@b1-systems.de>, kvm@vger.kernel.org,
	qemu-devel <qemu-devel@nongnu.org>
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from goliath.siemens.de ([192.35.17.28]:28967 "EHLO
	goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751383Ab1FTP72 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 20 Jun 2011 11:59:28 -0400
In-Reply-To: <4DFF6B20.7090107@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 2011-06-20 17:45, Avi Kivity wrote:
>> This series does need to introduce a QMP event notification upon
>> crash, so that the crash notification can be propagated to mgmt
>> layers above QEMU.
> 
> Yes.

I think the best way to deal with that is to stop the VM on guest panic.
There is already WIP to signal stop reasons via QMP. Maybe we need to
differentiate between hypervisor and guest triggered panics
(VMSTOP_GUEST_PANIC?), but the rest should come for free.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux