qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] gdbstub: do not restart crashed guest


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH] gdbstub: do not restart crashed guest
Date: Thu, 30 May 2013 13:55:50 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130513 Thunderbird/17.0.6

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 <address@hidden>
> Signed-off-by: Paolo Bonzini <address@hidden>
> ---
>  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 <address@hidden>

(
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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]