From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56115) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPYWZ-0006Yx-Tr for qemu-devel@nongnu.org; Mon, 17 Mar 2014 10:28:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WPYWT-0007Lm-TR for qemu-devel@nongnu.org; Mon, 17 Mar 2014 10:28:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45001) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPYWT-0007KE-KN for qemu-devel@nongnu.org; Mon, 17 Mar 2014 10:28:13 -0400 Message-ID: <53270678.8090901@redhat.com> Date: Mon, 17 Mar 2014 15:28:08 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] virtio device error reporting best practice? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dave Airlie , "qemu-devel@nongnu.org" Cc: Seiji Aguchi On 03/17/14 07:02, Dave Airlie wrote: > So I'm looking at how best to do virtio gpu device error reporting, > and how to deal with illegal stuff, > > I've two levels of errors I want to support, > > a) unrecoverable or bad guest kernel programming errors, > > b) per 3D context errors from the renderer backend, > > (b) I can easily report in an event queue and the guest kernel can in > theory blow away the offenders, this is how GL works with some > extensions, > > For (a) I can expect a response from every command I put into the main > GPU control queue, the response should always be no error, but in some > cases it will be because the guest hit some host resource error, or > asked for something insane, (guest kernel drivers would be broken in > most of these cases). > > Alternately I can use the separate event queue to send async errors > when the guest does something bad, > > I'm also considering adding some sort of flag in config space saying > the device needs a reset before it will continue doing anything, > > 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). If you grep qemu for it, you'll find such examples. Notably, "hw/virtio/virtio.c" is chock full of them; if the guest doesn't speak the basic protocol, there's nothing for the host to do. See also virtio-blk.c (missing or incorrect headers), virtio-net.c (similar protocol violations), virtio-scsi.c (wrong header size, bad config etc). For later, we have a use case on the horizon where all such exits -- not just virtio, but exit(1) or abort() on invalid guest behavior in general -- should be optionally coupled (dependent on the qemu command line) with an automatic dump-guest-memory, in order to help debugging the guest. Thanks Laszlo