From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/2] Introduce panic hypercall Date: Mon, 20 Jun 2011 18:45:36 +0300 Message-ID: <4DFF6B20.7090107@redhat.com> References: <1308577094-17551-1-git-send-email-gollub@b1-systems.de> <4DFF67CB.3060807@redhat.com> <20110620153825.GH13042@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Gollub , kvm@vger.kernel.org, qemu-devel To: "Daniel P. Berrange" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:9650 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753210Ab1FTPpn (ORCPT ); Mon, 20 Jun 2011 11:45:43 -0400 In-Reply-To: <20110620153825.GH13042@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 06/20/2011 06:38 PM, Daniel P. Berrange wrote: > On Mon, Jun 20, 2011 at 06:31:23PM +0300, Avi Kivity wrote: > > On 06/20/2011 04:38 PM, Daniel Gollub wrote: > > >Introduce panic hypercall to enable the crashing guest to notify the > > >host. This enables the host to run some actions as soon a guest > > >crashed (kernel panic). > > > > > >This patch series introduces the panic hypercall at the host end. > > >As well as the hypercall for KVM paravirtuliazed Linux guests, by > > >registering the hypercall to the panic_notifier_list. > > > > > >The basic idea is to create KVM crashdump automatically as soon the > > >guest paniced and power-cycle the VM (e.g. libvirt). > > > > This would be more easily done via a "panic device" (I/O port or > > memory-mapped address) that the guest hits. It would be intercepted > > by qemu without any new code in kvm.\ > > > > However, I'm not sure I see the gain. Most enterprisey guests > > already contain in-guest crash dumpers which provide more > > information than a qemu memory dump could, since they know exact > > load addresses etc. and are integrated with crash analysis tools. > > What do you have in mind? > > Well libvirt can capture a "core" file by doing 'virsh dump $GUESTNAME'. > This actually uses the QEMU monitor migration command to capture the > entire of QEMU memory. The 'crash' command line tool actually knows > how to analyse this data format as it would a normal kernel crashdump. Interesting. > I think having a way for a guest OS to notify the host that is has > crashed would be useful. libvirt could automatically do a crash > dump of the QEMU memory, or at least pause the guest CPUs and notify > the management app of the crash, which can then decide what todo. > You can also use tools like 'virt-dmesg' which uses libvirt to peek > into guest memory to extract the most recent kernel dmesg logs (even > if the guest OS itself is crashed& didn't manage to send them out > via netconsole or something else). I agree. But let's do this via a device, this way kvm need not be changed. Do ILO cards / IPMI support something like this? We could follow their lead in that case. > 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. -- error compiling committee.c: too many arguments to function