On Wed, Aug 21, 2013 at 10:17:49AM -0400, Luiz Capitulino wrote:
On Wed, 21 Aug 2013 14:43:11 +0200
Paolo Bonzini <pbonzini(a)redhat.com> wrote:
> Il 21/08/2013 14:42, Laszlo Ersek ha scritto:
> > (*) Hm I think I understand why. main_loop_should_exit(), when a reset
> > was requested *and* runstate_needs_reset() evaluated to true, used to
> > set the runstate to PAUSED -- I guess temporarily.
>
> Yes, this is the code that does the PANICKED -> PAUSED transition:
>
> if (runstate_needs_reset()) {
> runstate_set(RUN_STATE_PAUSED);
> }
>
> This is to move the system out of a runstate that needs_reset(), and
> make the subsequent "cont" work instead of hitting this:
>
> if (runstate_needs_reset()) {
> error_set(errp, QERR_RESET_REQUIRED);
> return;
> }
Yes. For those states issuing 'cont' won't put the guest to run again,
so you're required to reset the guest first.
I think the same reasoning went behind the PANICKED state, and for most
cases it's going to be disastrous to put the guest to run again,
Why will it? It will most likely just call halt a bit later.
but
I can understand that this is up user/mngt to decide this, not QEMU.
I don't have a problem with this patch as such, so
Acked-by: Michael S. Tsirkin <mst(a)redhat.com>
though I'm still not really sure why do we
want to block guest immediately on panic.
Why not let it call halt a bit later?
--
MST