From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LNrYD-0002Vm-Kn
	for qemu-devel@nongnu.org; Fri, 16 Jan 2009 11:28:05 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LNrY8-0002V4-6F
	for qemu-devel@nongnu.org; Fri, 16 Jan 2009 11:28:04 -0500
Received: from [199.232.76.173] (port=58514 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LNrY8-0002V1-0o
	for qemu-devel@nongnu.org; Fri, 16 Jan 2009 11:28:00 -0500
Received: from qw-out-1920.google.com ([74.125.92.145]:43915)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1LNrY7-0003aW-KC
	for qemu-devel@nongnu.org; Fri, 16 Jan 2009 11:27:59 -0500
Received: by qw-out-1920.google.com with SMTP id 5so361398qwc.4
	for <qemu-devel@nongnu.org>; Fri, 16 Jan 2009 08:27:58 -0800 (PST)
Message-ID: <4970B582.7040009@codemonkey.ws>
Date: Fri, 16 Jan 2009 10:27:46 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [PATCH] optionally specify vm stop message
References: <20090115103733.GA11299@redhat.com>	<496FA08E.4060806@codemonkey.ws>	<20090116071437.GB27165@redhat.com>	<4970A715.7020009@codemonkey.ws>
	<4970B4A1.3000106@siemens.com>
In-Reply-To: <4970B4A1.3000106@siemens.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Jan Kiszka wrote:
> Anthony Liguori wrote:
>   
>>>  Also non zero reasons a handled differently by vm_stop. Don't know
>>> why.
>>>   
>>>       
>> It's an ugly hack for gdbstub.  It notifies gdb when a breakpoint
>> occurs.  We have far too many state tracking mechanisms.  Anyway, gdb
>> can pass something like VM_STOP_BP and that can be used to trigger the
>> callback.
>>     
>
> It's not only used for breakpoints but any stop condition that should be
> reported to the gdb frontend (so far: EXCP_DEBUG and EXCP_INTERRUPT).
> Not sure, though, how to deal with ENOSPC - it's not a guest fault, it's
> a host problem. From that POV, gdb should not receive it.
>   

We already have a vm_change_state_handler that is invoked whenever a 
guest starts running or stops running.  gdb should be able to use that 
and look at env->exception_index, no?

Regards,

Anthony Liguori

> Nevertheless, gdb_vm_stopped should better do the filtering, not the
> caller of vm_stop by passing 0 for "any other reason gdb should be
> bothered with".
>
> Jan
>
>