From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [PATCH v8] kvm: notify host when the guest is panicked Date: Mon, 13 Aug 2012 17:24:52 -0300 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 Cc: Gleb Natapov , Jan Kiszka , qemu-devel , "linux-kernel@vger.kernel.org" , Avi Kivity , kvm list , KAMEZAWA Hiroyuki To: Eric Blake Return-path: Content-Disposition: inline In-Reply-To: <50295A17.8010404@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org 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.