From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38723) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biI4s-0007kh-4L for qemu-devel@nongnu.org; Fri, 09 Sep 2016 05:26:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1biI4m-0003z4-VU for qemu-devel@nongnu.org; Fri, 09 Sep 2016 05:26:29 -0400 Received: from 10.mo68.mail-out.ovh.net ([46.105.79.203]:60859) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biI4m-0003yn-Mr for qemu-devel@nongnu.org; Fri, 09 Sep 2016 05:26:24 -0400 Received: from player778.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo68.mail-out.ovh.net (Postfix) with ESMTP id 83080FF8C1E for ; Fri, 9 Sep 2016 11:26:23 +0200 (CEST) Date: Fri, 9 Sep 2016 11:26:17 +0200 From: Greg Kurz Message-ID: <20160909112617.3f9c90ef@bahia> In-Reply-To: <20160909105305.688fde3d.cornelia.huck@de.ibm.com> References: <147326875705.8546.11347276277137015855.stgit@bahia.lan> <147326876478.8546.16045138068342092499.stgit@bahia.lan> <20160908105926.0d968e64.cornelia.huck@de.ibm.com> <20160908111216.12a1b562@bahia> <20160908175237-mutt-send-email-mst@kernel.org> <20160908170447.2d864945.cornelia.huck@de.ibm.com> <20160908181732-mutt-send-email-mst@kernel.org> <20160908182652.2cf51ac0@bahia> <20160908194939-mutt-send-email-mst@kernel.org> <20160909103053.7f2f7057.cornelia.huck@de.ibm.com> <20160909104625.648385f1@bahia> <20160909105305.688fde3d.cornelia.huck@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] virtio-9p: print error message and exit instead of BUG_ON() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: "Michael S. Tsirkin" , qemu-devel@nongnu.org, "Aneesh Kumar K.V" On Fri, 9 Sep 2016 10:53:05 +0200 Cornelia Huck wrote: > On Fri, 9 Sep 2016 10:46:25 +0200 > Greg Kurz wrote: > > > On Fri, 9 Sep 2016 10:30:53 +0200 > > Cornelia Huck wrote: > > > > > On Thu, 8 Sep 2016 19:55:16 +0300 > > > "Michael S. Tsirkin" wrote: > > > > > > > On Thu, Sep 08, 2016 at 06:26:52PM +0200, Greg Kurz wrote: > > > > > On Thu, 8 Sep 2016 18:19:27 +0300 > > > > > "Michael S. Tsirkin" wrote: > > > > > > > > > > > On Thu, Sep 08, 2016 at 05:04:47PM +0200, Cornelia Huck wrote: > > > > > > > On Thu, 8 Sep 2016 18:00:28 +0300 > > > > > > > "Michael S. Tsirkin" wrote: > > > > > > > > > > > > > > > On Thu, Sep 08, 2016 at 11:12:16AM +0200, Greg Kurz wrote: > > > > > > > > If it continues > > > > > execution, this means we're expecting the guest or the host to do something > > > > > to fix the error condition. This requires QEMU to emit an event of some > > > > > sort, but not necessarily to log an error message in a file. I guess this > > > > > depends if QEMU is run by some tooling, or by a human. > > > > > > > > I'm not sure we need an event if tools are not expected to > > > > do anything with it. If we limit # of times error > > > > is printed, tools will need to reset this counter, > > > > so we will need an event on overflow. > > > > > > If the device goes into a broken state, it should be discoverable from > > > outside. I'm not sure we need an actual event signalling this if this > > > happens due to the guest doing something wrong: That would be a task > > > for tools monitoring _inside_ the guest. > > > > Well, in case of a virtio device being broken, section 2.1.2 in the spec > > suggests to set the status to DEVICE_NEEDS_RESET and to notify it to > > the guest (aka. event signalling). I'll send a patch shortly. > > Stefan had already sent > <1460467534-29147-4-git-send-email-stefanha@redhat.com> ages ago, but > it has not yet made it anywhere... > I don't know what to do with this message-id :\ > Anyhow, I was concerned with host signalling (sorry for being unclear), > and I still do not think we need to alert host monitoring software to > guest stupidity. > I agree. Sorry if my poor wording made you (and others) think I was suggesting that :) My point was that if QEMU exits because of guest stupidity, you are forced to error_report() something to the host, but this is really suboptimal (even if BUG_ON is worse)... then there was that discussion about log files getting to big, but I don't even know how we came there, as it does not really make sense when QEMU exits. > > > > > For tools monitoring the > > > health of the machine (from the host perspective), the discovery > > > interface would probably be enough? > > > > > > > Yeah, probably. > > > > Cheers. > > > > -- > > Greg > > >