| Message ID | 1369912840-18577-1-git-send-email-pbonzini@redhat.com |
|---|---|
| State | New |
| Headers | show |
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.kiszka@siemens.com> > Signed-off-by: Paolo Bonzini <pbonzini@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 <lersek@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
On Thu, 30 May 2013 13:55:50 +0200 Laszlo Ersek <lersek@redhat.com> wrote: > 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.kiszka@siemens.com> > > Signed-off-by: Paolo Bonzini <pbonzini@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 <lersek@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? I honestly don't remember if I took into account the explanation you gave below. You're right that a stopped guest can't suspend. > > 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 >
Applied. Thanks. Regards, Anthony Liguori
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 }
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.kiszka@siemens.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- gdbstub.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)