From: Marcelo Tosatti <mtosatti@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Eric Blake <eblake@redhat.com>,
Wen Congyang <wency@cn.fujitsu.com>,
kvm list <kvm@vger.kernel.org>,
Jan Kiszka <jan.kiszka@siemens.com>,
qemu-devel <qemu-devel@nongnu.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Avi Kivity <avi@redhat.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
Date: Tue, 14 Aug 2012 12:29:38 -0300 [thread overview]
Message-ID: <20120814152938.GC14582@amt.cnet> (raw)
In-Reply-To: <20120814074748.GE11194@redhat.com>
On Tue, Aug 14, 2012 at 10:47:48AM +0300, Gleb Natapov wrote:
> On Mon, Aug 13, 2012 at 05:24:52PM -0300, Marcelo Tosatti wrote:
> > 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?
> >
> It is not zero config (guests do not send console output to serial by
> default). If vm users want to use serial for its working console panic
> notification will trigger every time user examines dmesg with "Kernel
> panic - not syncing" in it.
Ok, then it would have to be a dedicated serial console which starts
to become funny.
Use a simple virtio device, then, it starts early enough (or can be made
to) during kernel init for most relevant production panics, and works
for all architectures.
next prev parent reply other threads:[~2012-08-14 15:37 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-08 2:43 [PATCH v8] kvm: notify host when the guest is panicked Wen Congyang
2012-08-08 2:44 ` [PATCH v8 1/6] start vm after reseting it Wen Congyang
2012-08-08 2:45 ` [PATCH v8 2/6] kvm: Update kernel headers Wen Congyang
2012-08-08 2:45 ` [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED Wen Congyang
2012-08-08 2:46 ` [PATCH v8 4/6] add a new qevent: QEVENT_GUEST_PANICKED Wen Congyang
2012-08-08 2:47 ` [PATCH v8 5/6] introduce a new qom device to deal with panicked event Wen Congyang
2012-08-08 19:01 ` [Qemu-devel] " Blue Swirl
2012-08-22 7:30 ` Wen Congyang
2012-08-25 7:36 ` Blue Swirl
2012-08-08 2:47 ` [PATCH v8 6/6] allower the user to disable pv event support Wen Congyang
2012-08-08 9:12 ` [PATCH v8] kvm: notify host when the guest is panicked Andrew Jones
2012-08-08 9:28 ` Wen Congyang
2012-08-13 18:21 ` Marcelo Tosatti
2012-08-13 19:48 ` [Qemu-devel] " Eric Blake
2012-08-13 20:24 ` Marcelo Tosatti
2012-08-14 7:47 ` Gleb Natapov
2012-08-14 15:29 ` Marcelo Tosatti [this message]
2012-08-14 15:50 ` Gleb Natapov
2012-08-14 8:56 ` Daniel P. Berrange
2012-08-14 10:42 ` Jan Kiszka
2012-08-14 14:55 ` Yan Vugenfirer
2012-08-14 15:01 ` Jan Kiszka
2012-08-14 15:42 ` Marcelo Tosatti
2012-08-14 18:53 ` [Qemu-devel] " Anthony Liguori
2012-08-14 19:19 ` Marcelo Tosatti
2012-08-14 19:35 ` Anthony Liguori
2012-08-14 20:53 ` Marcelo Tosatti
2012-08-14 22:59 ` Anthony Liguori
2012-08-15 0:25 ` [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked\ Marcelo Tosatti
2012-08-22 6:33 ` [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked Wen Congyang
2012-08-15 9:56 ` Gleb Natapov
2012-08-15 11:42 ` Yan Vugenfirer
2012-08-15 11:38 ` Yan Vugenfirer
2012-08-14 19:58 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120814152938.GC14582@amt.cnet \
--to=mtosatti@redhat.com \
--cc=avi@redhat.com \
--cc=eblake@redhat.com \
--cc=gleb@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=wency@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).