From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49828) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPtOx-0008SH-1A for qemu-devel@nongnu.org; Tue, 18 Mar 2014 08:45:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WPtOq-0000YR-Ql for qemu-devel@nongnu.org; Tue, 18 Mar 2014 08:45:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43496) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPtOq-0000YM-G5 for qemu-devel@nongnu.org; Tue, 18 Mar 2014 08:45:44 -0400 Date: Tue, 18 Mar 2014 13:45:37 +0100 From: Kevin Wolf Message-ID: <20140318124537.GM4607@noname.str.redhat.com> References: <53270678.8090901@redhat.com> <53270B6D.6030602@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53270B6D.6030602@redhat.com> Subject: Re: [Qemu-devel] virtio device error reporting best practice? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: Peter Maydell , Dave Airlie , "qemu-devel@nongnu.org" , Seiji Aguchi Am 17.03.2014 um 15:49 hat Laszlo Ersek geschrieben: > On 03/17/14 15:40, Peter Maydell wrote: > > On 17 March 2014 14:28, Laszlo Ersek wrote: > >> On 03/17/14 07:02, Dave Airlie wrote: > >>> The main reason I'm considering this stuff is for security reasons if > >>> the guest asks for something really illegal or crazy what should the > >>> expected behaviour of the host be? (at least secure I know that). > >> > >> exit(1). > > > > No thanks -- the guest should never be able to cause QEMU > > to exit (in an ideal world). Use > > qemu_log_mask(LOG_GUEST_ERROR, ...) > > and continue. > > How do you continue with a garbled virtio ring? Say you detect an error > that would cause integer overflow or buffer overflow in the host, a > clear virtio protocol violation etc. Error reporting is just one thing > -- what are the semantics of continuing? Stop processing the ring until the guest resets it. You don't want a buggy guest driver to crash the whole system needlessly, it's good enough if the one device doesn't work any more. Also, consider that a qemu process can be doing entirely different things, like executing block jobs or hosting the builtin NBD server (and being a QMP server, too), and you don't want to allow the guest to interrupt this. As far as I can tell, exit() also doesn't do bdrv_close_all(), so it's an unclean shutdown that may leave images in an inconsistent state. And this is only the block layer perspective on it. Not sure about how well other subsystems cope with unclean shutdowns. Not to forget that a user will be surprised if his qemu process is suddenly gone without him intentionally shutting down the VM. An error message indicating the failing device inside the guest is much nicer. tl;dr: exit() calls in hw/ do exist, but these are longstanding bugs, not examples to follow. Kevin