From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34495) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T11Cu-00005Y-Br for qemu-devel@nongnu.org; Mon, 13 Aug 2012 16:25:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T11Cs-0007D7-Ki for qemu-devel@nongnu.org; Mon, 13 Aug 2012 16:25:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58053) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T11Cs-0007CL-CO for qemu-devel@nongnu.org; Mon, 13 Aug 2012 16:25:46 -0400 Date: Mon, 13 Aug 2012 17:24:52 -0300 From: Marcelo Tosatti Message-ID: <20120813202452.GA10321@amt.cnet> References: <5021D235.4050800@cn.fujitsu.com> <20120813182132.GB25268@amt.cnet> <50295A17.8010404@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50295A17.8010404@redhat.com> Subject: Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Gleb Natapov , Jan Kiszka , qemu-devel , "linux-kernel@vger.kernel.org" , Avi Kivity , kvm list , KAMEZAWA Hiroyuki On Mon, Aug 13, 2012 at 01:48:39PM -0600, Eric Blake wrote: > On 08/13/2012 12:21 PM, Marcelo Tosatti wrote: > > On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: > >> We can know the guest is panicked when the guest runs on xen. > >> But we do not have such feature on kvm. > >> > >> Another purpose of this feature is: management app(for example: > >> libvirt) can do auto dump when the guest is panicked. If management > >> app does not do auto dump, the guest's user can do dump by hand if > >> he sees the guest is panicked. > >> > >> We have three solutions to implement this feature: > >> 1. use vmcall > >> 2. use I/O port > >> 3. use virtio-serial. > >> > >> We have decided to avoid touching hypervisor. The reason why I choose > >> choose the I/O port is: > >> 1. it is easier to implememt > >> 2. it does not depend any virtual device > >> 3. it can work when starting the kernel > > > > How about searching for the "Kernel panic - not syncing" string > > in the guests serial output? Say libvirtd could take an action upon > > that? > > > > Advantages: > > - It works for all architectures. > > - It does not depend on any virtual device. > > But it _does_ depend on a serial console, Which already exists and is supported. > and furthermore requires > libvirt to tee the serial console (right now, libvirt can treat the > console as an opaque pass-through to the end user, but if you expect > libvirt to parse the serial console for a particular string, you've lost > some efficiency). > > > - It works as early as serial console output does (panics before > > that should be rare). > > - It allows you to see why the guest panicked. > > I think your arguments for a serial console have already been made and > refuted in earlier versions of this patch series, which is WHY this > series is still applicable. Refuted why, exactly? Efficiency to parse serial console output in libvirt should not be a major issue surely? Either way: The device should be arch independent, as "panic" is not specific to a particular architecture. For example virtio which would also work on S390. Custom IO port == virtual device, so that depends on virtual device already.