On Thu, Oct 31, 2013 at 04:56:07PM +0100, Paolo Bonzini wrote:
> Il 31/10/2013 16:45, Michael S. Tsirkin ha scritto:
> > On Thu, Oct 31, 2013 at 04:26:13PM +0100, Paolo Bonzini wrote:
> >> Il 31/10/2013 16:09, Michael S. Tsirkin ha scritto:
> >>> 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.
> >>
> >> No, we cannot. Reboot-in-guest-after-dump-on-host is a perfectly fine
> >> configuration.
> >>
> >>>>>>> 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?
> >>
> >> If the guest panics while for some reason libvirtd went down, libvirt
> >> can see what happened. It is similar to the "I/O error" state in this
> >> respect.
> >>
> >>> Looks like all transitions from paused state should be allowed from panicked
> >>> state. So why keep it separate?
> >>
> >> Because you can poll for the state instead of watching an event.
> >
> > I see. Maybe it was a mistake to use a separate runtime state for
> > this, but oh well.
>
> Yes, we should have had a list of "reasons" why a guest is stopped (I/O
> error, panic, gdb, ...) and a command to clear one or more of them;
> there can be paused/running/waiting-for-migration/... states, but many
> of the states we have are not necessarily in mutual exclusion.
>
> But we cannot really choose now.
>
> > So it should be exactly like paused, we can just find all transitions
> > from PAUSED and it should be same for PANICKED?
> > Why isn't DEBUG allowed from PAUSED but allowed from PANICKED then?
> > Maybe it should be allowed for PAUSED?
>
> PANICKED->DEBUG was added by commit bc7d0e667. That commit can be
> reverted if the panicked state is removed from runstate_needs_reset.
>
> Paolo
Okay so let's drop the code duplication and explicitly make
them the same?
Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx>
diff --git a/vl.c b/vl.c
index 46c29c4..e12d317 100644
--- a/vl.c
+++ b/vl.c
@@ -638,10 +638,6 @@ static const RunStateTransition runstate_transitions_def[] = {
{ RUN_STATE_WATCHDOG, RUN_STATE_RUNNING },
{ RUN_STATE_WATCHDOG, RUN_STATE_FINISH_MIGRATE },
- { RUN_STATE_GUEST_PANICKED, RUN_STATE_PAUSED },
- { RUN_STATE_GUEST_PANICKED, RUN_STATE_FINISH_MIGRATE },
- { RUN_STATE_GUEST_PANICKED, RUN_STATE_DEBUG },
-
{ RUN_STATE_MAX, RUN_STATE_MAX },
};
@@ -660,6 +656,12 @@ static void runstate_init(void)
for (p = &runstate_transitions_def[0]; p->from != RUN_STATE_MAX; p++) {
runstate_valid_transitions[p->from][p->to] = true;
+ /* Panicked state is same as paused, we only made it different so
+ * management can detect a panic.
+ */
+ if (p->from == RUN_STATE_PAUSED) {
+ runstate_valid_transitions[RUN_STATE_GUEST_PANICKED][p->to] = true;
+ }
}
}
@@ -686,8 +688,7 @@ int runstate_is_running(void)
bool runstate_needs_reset(void)
{
return runstate_check(RUN_STATE_INTERNAL_ERROR) ||
- runstate_check(RUN_STATE_SHUTDOWN) ||
- runstate_check(RUN_STATE_GUEST_PANICKED);
+ runstate_check(RUN_STATE_SHUTDOWN);
}
StatusInfo *qmp_query_status(Error **errp)
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list