From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNrgM-0003dU-So for qemu-devel@nongnu.org; Fri, 16 Jan 2009 11:36:30 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNrgL-0003cX-C5 for qemu-devel@nongnu.org; Fri, 16 Jan 2009 11:36:30 -0500 Received: from [199.232.76.173] (port=55255 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNrgL-0003cR-3S for qemu-devel@nongnu.org; Fri, 16 Jan 2009 11:36:29 -0500 Received: from lizzard.sbs.de ([194.138.37.39]:20671) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LNrgK-0004U6-Fr for qemu-devel@nongnu.org; Fri, 16 Jan 2009 11:36:28 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n0GGaPFG020626 for ; Fri, 16 Jan 2009 17:36:25 +0100 Received: from [139.25.109.167] (mchn012c.ww002.siemens.net [139.25.109.167] (may be forged)) by mail2.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n0GGaOY3019254 for ; Fri, 16 Jan 2009 17:36:25 +0100 Message-ID: <4970B78B.8070900@siemens.com> Date: Fri, 16 Jan 2009 17:36:27 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <20090115103733.GA11299@redhat.com> <496FA08E.4060806@codemonkey.ws> <20090116071437.GB27165@redhat.com> <4970A715.7020009@codemonkey.ws> <4970B4A1.3000106@siemens.com> <4970B582.7040009@codemonkey.ws> In-Reply-To: <4970B582.7040009@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] optionally specify vm stop message Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Anthony Liguori wrote: > 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? I don't think env->exception_index is set when you issue "stop" from the monitor, e.g. Moreover, that would be an ugly (out-of-band) API as well. Jan -- Siemens AG, Corporate Technology, CT SE 26 Corporate Competence Center Embedded Linux