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.
>> > 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.
If it's resumable how is it different from PAUSED?
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
Looks like all transitions from paused state should be allowed from panicked
state. So why keep it separate?