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@xxxxxxxxxx> 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@xxxxxxxxxx>
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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list