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.
> > 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 <oncrash> 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.
Basically it's patches 1 and 2 at
http://permalink.gmane.org/gmane.comp.emulators.qemu/229131. Rebasing
will fix the problem highlighted in the commit message of patch 2.
Paolo