From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36503) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VC5BG-00014c-Ic for qemu-devel@nongnu.org; Wed, 21 Aug 2013 05:58:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VC5BA-0004P9-GB for qemu-devel@nongnu.org; Wed, 21 Aug 2013 05:58:22 -0400 Received: from [222.73.24.84] (port=33377 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VC5BA-0004O2-2U for qemu-devel@nongnu.org; Wed, 21 Aug 2013 05:58:16 -0400 Date: Wed, 21 Aug 2013 17:56:53 +0800 From: Hu Tao Message-ID: <20130821095653.GD32733@localhost.localdomain> References: <1376233843-19410-1-git-send-email-marcel.a@redhat.com> <520B2B8D.8070401@redhat.com> <1377072197.1888.35.camel@localhost.localdomain> <521477CF.4010703@redhat.com> <20130821094237.GA4757@redhat.com> MIME-Version: 1.0 In-Reply-To: <20130821094237.GA4757@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Subject: Re: [Qemu-devel] [PATCH for-1.6 V2 0/2] pvpanic: Separate pvpanic from machine type List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: aliguori@us.ibm.com, gleb@redhat.com, Marcel Apfelbaum , qemu-devel@nongnu.org, Ronen Hod , kraxel@redhat.com, Paolo Bonzini , afaerber@suse.de, vrozenfe@redhat.com On Wed, Aug 21, 2013 at 12:42:37PM +0300, Michael S. Tsirkin wrote: > On Wed, Aug 21, 2013 at 10:18:23AM +0200, Paolo Bonzini wrote: > > Il 21/08/2013 10:03, Marcel Apfelbaum ha scritto: > > > On Wed, 2013-08-14 at 10:02 +0300, Ronen Hod wrote: > > >> How about adding a flag that tells QEMU whether to pause or reboot the guest > > >> after the panic? > > >> We cannot assume that we always have a management layer that takes care > > >> of this. > > >> One example is Microsoft's WHQL that deliberately generates a BSOD, and then > > >> examines the dump files. > > > After this patch the pvpanic is not part of the global devices anymore so just > > > don't enable it if you want to reboot on BSOD. > > > In my opinion "reboot after panic" equals "run without pvpanic device" > > > > This is not entirely possible, since "reboot after panic" is a guest > > setting while "run without pvpanic device" is a host setting (that the > > guest administrator may not even have access to: Ronen's case is a good > > example of this, because the "administrator" there is the WHQL harness). > > > > However, I think this is a driver problem. The driver should just probe > > the "reboot after panic" setting and not issue the outb to the pvpanic port. > > > > Paolo > > This might or might not be possible on different OS-es. > What exactly is gained by doing vmstop on outb of pvpanic? This gives management apps (libvirt) a chance to take care of the situation. It can reboot, poweroff, or dump guest. > We want a notification about the panic but > adding yet another way to halt seems kind of useless. > Why not let VM continue? If it wants to stop it > can always call halt. >