From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38368) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vbu8r-0005n6-C9 for qemu-devel@nongnu.org; Thu, 31 Oct 2013 11:26:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vbu8j-0005cn-Jm for qemu-devel@nongnu.org; Thu, 31 Oct 2013 11:26:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8359) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vbu8j-0005ce-AI for qemu-devel@nongnu.org; Thu, 31 Oct 2013 11:26:29 -0400 Message-ID: <52727695.8080007@redhat.com> Date: Thu, 31 Oct 2013 16:26:13 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1377187852-11192-1-git-send-email-pbonzini@redhat.com> <20131024023903.GD16757@G08FNSTD100614.fnst.cn.fujitsu.com> <20131031143004.GA9948@redhat.com> <52726A0B.4080805@redhat.com> <52726B95.6020006@redhat.com> <20131031145234.GC9948@redhat.com> <52726FAA.6000502@redhat.com> <20131031150955.GE9948@redhat.com> In-Reply-To: <20131031150955.GE9948@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] pvpanic plans? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: pkrempa@redhat.com, lersek@redhat.com, marcel.a@redhat.com, libvir-list@redhat.com, Hu Tao , qemu-devel@nongnu.org, armbru@redhat.com, rhod@redhat.com, kraxel@redhat.com, anthony@codemonkey.ws, lcapitulino@redhat.com, afaerber@suse.de Il 31/10/2013 16:09, Michael S. Tsirkin ha scritto: > On Thu, Oct 31, 2013 at 03:56:42PM +0100, Paolo Bonzini wrote: >> Il 31/10/2013 15:52, Michael S. Tsirkin ha scritto: >>>>> Yes, it does. >>> What does it break exactly? >> >> The point of a panicked event is to examine the guest at a particular >> moment in time (e.g. host-initiated crash dump). If you let the guest >> run, it may reboot and prevent you from getting a meaningful dump. > > Well we trust guest anyway, so I think we can trust it to call halt. No, we cannot. Reboot-in-guest-after-dump-on-host is a perfectly fine configuration. >>>>> But I think that, once we make the pvpanic device is >>>>> optional, to a large extent there is no bug. Adding the pvpanic >>>>> device to the VM will make libvirt obey instead of the >>>>> in-guest setting, and that's it. >>>>> >>>>> Two months have passed and no casualties have been reported due to >>>>> pvpanic. Let's just remove the auto-pvpanic from all machine types in >>>>> 1.7 (yes, that's backwards incompatible in a strict sense), document >>>>> it in the release notes, and hope that the old QEMU versions with >>>>> mandatory pvpanic die of old age. >>> >>> Nod. I'm fine with that. >>> >>> I think we still need to do get rid of the PANICKED state somehow. >>> If we can't replace it with RUNNING state, let's replace it with PAUSED. >>> >>> For example, you can't continue from panicked for some reason. >>> You can't do a reset. But you can pause and then continue. >> >> We need to keep the PANICKED state, but we can make it a normal >> "resumable" state. > > If it's resumable how is it different from PAUSED? If the guest panics while for some reason libvirtd went down, libvirt can see what happened. It is similar to the "I/O error" state in this respect. > Looks like all transitions from paused state should be allowed from panicked > state. So why keep it separate? Because you can poll for the state instead of watching an event. Paolo