From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNrpN-0008Eg-N2 for qemu-devel@nongnu.org; Fri, 16 Jan 2009 11:45:49 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNrpM-0008EM-0b for qemu-devel@nongnu.org; Fri, 16 Jan 2009 11:45:49 -0500 Received: from [199.232.76.173] (port=50269 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNrpL-0008EG-Pf for qemu-devel@nongnu.org; Fri, 16 Jan 2009 11:45:47 -0500 Received: from gecko.sbs.de ([194.138.37.40]:17629) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LNrpL-0005gH-5h for qemu-devel@nongnu.org; Fri, 16 Jan 2009 11:45:47 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n0GGjgDc019465 for ; Fri, 16 Jan 2009 17:45:42 +0100 Received: from [139.25.109.167] (mchn012c.mchp.siemens.de [139.25.109.167] (may be forged)) by mail1.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n0GGjgkA007353 for ; Fri, 16 Jan 2009 17:45:42 +0100 Message-ID: <4970B9B9.1030101@siemens.com> Date: Fri, 16 Jan 2009 17:45:45 +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> <4970B78B.8070900@siemens.com> In-Reply-To: <4970B78B.8070900@siemens.com> 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 Jan Kiszka wrote: > 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. > The point is that vm_stop can be issued from any context, not just from a vcpu. So there may be no env channel at this point. Jan -- Siemens AG, Corporate Technology, CT SE 26 Corporate Competence Center Embedded Linux