On 05/30/13 13:20, Paolo Bonzini wrote: > If a guest has crashed with an internal error or similar, detaching > gdb (or any other debugger action) should not restart it. > > Cc: Jan Kiszka <jan.kis...@siemens.com> > Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> > --- > gdbstub.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/gdbstub.c b/gdbstub.c > index e80e1d3..90e54cb 100644 > --- a/gdbstub.c > +++ b/gdbstub.c > @@ -371,7 +371,9 @@ static inline void gdb_continue(GDBState *s) > #ifdef CONFIG_USER_ONLY > s->running_state = 1; > #else > - vm_start(); > + if (runstate_check(RUN_STATE_DEBUG)) { > + vm_start(); > + } > #endif > } > >
I sought to check the gdb_continue() call sites, and uses of RUN_STATE_DEBUG. Seems reasonable. Reviewed-by: Laszlo Ersek <ler...@redhat.com> ( FWIW I wonder why in commit ad02b96a Luiz allowed DEBUG -> SUSPENDED. As far as I understand, when the debugger is attached, the guest is not running, hence it can't go directly to RUN_STATE_SUSPENDED. Maybe due to a concurrent monitor command? Technically it does seem possible; from main_loop_should_exit(): if (qemu_debug_requested()) { vm_stop(RUN_STATE_DEBUG); } if (qemu_suspend_requested()) { qemu_system_suspend(); } Both requests could become pending during one iteration of the loop, and the next iteration will see both of them. OK. ) Laszlo