From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNrUI-0001Q6-CA for qemu-devel@nongnu.org; Fri, 16 Jan 2009 11:24:02 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNrUH-0001Pu-W8 for qemu-devel@nongnu.org; Fri, 16 Jan 2009 11:24:02 -0500 Received: from [199.232.76.173] (port=58448 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNrUH-0001Pr-Pq for qemu-devel@nongnu.org; Fri, 16 Jan 2009 11:24:01 -0500 Received: from lizzard.sbs.de ([194.138.37.39]:16161) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LNrUH-0003B1-AG for qemu-devel@nongnu.org; Fri, 16 Jan 2009 11:24:01 -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 n0GGNxSv010653 for ; Fri, 16 Jan 2009 17:23:59 +0100 Received: from [139.25.109.167] (mchn012c.mchp.siemens.de [139.25.109.167] (may be forged)) by mail2.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n0GGNxSl014122 for ; Fri, 16 Jan 2009 17:23:59 +0100 Message-ID: <4970B4A1.3000106@siemens.com> Date: Fri, 16 Jan 2009 17:24:01 +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> In-Reply-To: <4970A715.7020009@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: > Gleb Natapov wrote: >> On Thu, Jan 15, 2009 at 02:46:06PM -0600, Anthony Liguori wrote: >> >>> Gleb Natapov wrote: >>> >>>> Should be applied on top of ENOSPC series. >>>> >>> How about just adding a new vm_stop reason? That will work out >>> better when we introduce the improved monitor. >>> >>> >> We may want to specify different message for the same reason. For >> instance we may want to print the name of the file we failed to write >> to. > > I'm thinking about this from a management tool perspective. When we > have a better monitor interface, this would generate an async > notification. Instead of generating an arbitrary string, it could send > a reason code that has a well defined meaning. > > For now, within vm_stop, it can say if (reason == VM_STOP_ENOSPC) > printf("ran out of space"); or something. > > There are other places we stop a vm, like when -no-shutdown is used, > where using a reason code would be very useful. > >> 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. 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 -- Siemens AG, Corporate Technology, CT SE 26 Corporate Competence Center Embedded Linux