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]
Message-ID: <20120612124045.GK10153@redhat.com>
Date:	Tue, 12 Jun 2012 13:40:45 +0100
From:	"Daniel P. Berrange" <berrange@...hat.com>
To:	Luiz Capitulino <lcapitulino@...hat.com>
Cc:	Wen Congyang <wency@...fujitsu.com>,
	kvm list <kvm@...r.kernel.org>,
	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>,
	Jan Kiszka <jan.kiszka@...mens.com>,
	Gleb Natapov <gleb@...hat.com>
Subject: Re: [Qemu-devel] [PATCH 3/3] deal with guest panicked event

On Tue, Jun 12, 2012 at 09:35:04AM -0300, Luiz Capitulino wrote:
> On Tue, 12 Jun 2012 14:55:37 +0800
> Wen Congyang <wency@...fujitsu.com> wrote:
> 
> > >> +static void panicked_perform_action(void)
> > >> +{
> > >> +    switch(panicked_action) {
> > >> +    case PANICKED_REPORT:
> > >> +        panicked_mon_event("report");
> > >> +        break;
> > >> +
> > >> +    case PANICKED_PAUSE:
> > >> +        panicked_mon_event("pause");
> > >> +        vm_stop(RUN_STATE_GUEST_PANICKED);
> > >> +        break;
> > >> +
> > >> +    case PANICKED_QUIT:
> > >> +        panicked_mon_event("quit");
> > >> +        exit(0);
> > >> +        break;
> > >> +    }
> > > 
> > > Having the data argument is not needed/wanted. The mngt app can guess it if it
> > > needs to know it, but I think it doesn't want to.
> > 
> > Libvirt will do something when the kernel is panicked, so it should know the action
> > in qemu side.
> 
> But the action will be set by libvirt itself, no?

Sure, but the whole world isn't libvirt. If the process listening to the
monitor is not the same as the process which launched the VM, then I
think including the action is worthwhile. Besides, the way Wen has done
this is identical to what we already do with QEVENT_WATCHDOG and I think
it is desirable to keep consistency here.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
--
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