From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:44794)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1Ui2D8-0001uG-Fz
	for qemu-devel@nongnu.org; Thu, 30 May 2013 08:44:11 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1Ui2D3-0001u5-4E
	for qemu-devel@nongnu.org; Thu, 30 May 2013 08:44:06 -0400
Received: from mx1.redhat.com ([209.132.183.28]:15499)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1Ui2D2-0001tr-SQ
	for qemu-devel@nongnu.org; Thu, 30 May 2013 08:44:01 -0400
Date: Thu, 30 May 2013 08:43:58 -0400
From: Luiz Capitulino <lcapitulino@redhat.com>
Message-ID: <20130530084358.35365285@redhat.com>
In-Reply-To: <51A73E46.5050003@redhat.com>
References: <1369912840-18577-1-git-send-email-pbonzini@redhat.com>
	<51A73E46.5050003@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] gdbstub: do not restart crashed guest
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org, Jan Kiszka <jan.kiszka@siemens.com>

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
>