lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 14 Aug 2012 10:47:48 +0300
From:	Gleb Natapov <gleb@...hat.com>
To:	Marcelo Tosatti <mtosatti@...hat.com>
Cc:	Eric Blake <eblake@...hat.com>,
	Wen Congyang <wency@...fujitsu.com>,
	kvm list <kvm@...r.kernel.org>,
	Jan Kiszka <jan.kiszka@...mens.com>,
	qemu-devel <qemu-devel@...gnu.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Avi Kivity <avi@...hat.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Subject: Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is
 panicked

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.

--
			Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ