From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33138) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VC9q9-0006B4-Sg for qemu-devel@nongnu.org; Wed, 21 Aug 2013 10:56:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VC9q1-0001Vx-Cv for qemu-devel@nongnu.org; Wed, 21 Aug 2013 10:56:53 -0400 Date: Wed, 21 Aug 2013 17:58:22 +0300 From: "Michael S. Tsirkin" Message-ID: <20130821145822.GB10839@redhat.com> References: <1377086477-19553-1-git-send-email-pbonzini@redhat.com> <5214B5BE.1030906@redhat.com> <5214B5DF.5040100@redhat.com> <20130821101749.5b95b2e4@redhat.com> <20130821143030.GA10645@redhat.com> <5214D0C4.2010503@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5214D0C4.2010503@redhat.com> Subject: Re: [Qemu-devel] [PATCH] vl: allow "cont" from panicked state List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: pkrempa@redhat.com, marcel.a@redhat.com, libvir-list@redhat.com, hutao@cn.fujitsu.com, qemu-stable@nongnu.org, qemu-devel@nongnu.org, rhod@redhat.com, kraxel@redhat.com, anthony@codemonkey.ws, Luiz Capitulino , Laszlo Ersek , afaerber@suse.de On Wed, Aug 21, 2013 at 04:37:56PM +0200, Paolo Bonzini wrote: > Il 21/08/2013 16:30, Michael S. Tsirkin ha scritto: > >> I think the same reasoning went behind the PANICKED state, and for most > >> cases it's going to be disastrous to put the guest to run again, > > > > Why will it? It will most likely just call halt a bit later. > > I agree. > > >> but I can understand that this is up user/mngt to decide this, not QEMU. > > > > I don't have a problem with this patch as such, so > > > > Acked-by: Michael S. Tsirkin > > > > though I'm still not really sure why do we > > want to block guest immediately on panic. > > Why not let it call halt a bit later? > > To make sure the panic is detected, and action taken, in the host even > if management has crashed at the time. I'm not sure I get the reference to management crashing - we just need to maintain "panicked" state to make sure info is not lost ... > For example, even if you have > reboot-on-panic active, management has time to take a core dump of the > paused guest _before_ the reboot. > > Paolo but this sounds like a good reason to support synchronous panic events. -- MST