Re: [Qemu-devel] [PATCH for-1.6 V2 0/2] pvpanic: Separate pvpanic from machine type

[Hu Tao]

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.
>