From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60357) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Shi5h-0006j4-M7 for qemu-devel@nongnu.org; Thu, 21 Jun 2012 10:10:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Shi5b-00088k-Dd for qemu-devel@nongnu.org; Thu, 21 Jun 2012 10:10:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:3788) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Shi5b-00087v-5f for qemu-devel@nongnu.org; Thu, 21 Jun 2012 10:10:27 -0400 Date: Thu, 21 Jun 2012 17:10:16 +0300 From: "Michael S. Tsirkin" Message-ID: <20120621141016.GB25285@redhat.com> References: <1340087992-2399-1-git-send-email-benh@kernel.crashing.org> <1340087992-2399-5-git-send-email-benh@kernel.crashing.org> <4FE23E30.50302@codemonkey.ws> <1340228168.28143.178.camel@pasglop> <4FE2434D.2010901@codemonkey.ws> <1340229726.28143.200.camel@pasglop> <20120621073338.GA31732@redhat.com> <4FE319DE.7070809@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FE319DE.7070809@codemonkey.ws> Subject: Re: [Qemu-devel] [PATCH 04/13] usb-ohci: Use universal DMA helper functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Gerd Hoffmann , qemu-devel@nongnu.org, David Gibson On Thu, Jun 21, 2012 at 07:55:58AM -0500, Anthony Liguori wrote: > On 06/21/2012 02:33 AM, Michael S. Tsirkin wrote: > >On Thu, Jun 21, 2012 at 08:02:06AM +1000, Benjamin Herrenschmidt wrote: > >>On Wed, 2012-06-20 at 16:40 -0500, Anthony Liguori wrote: > >> > >>>Well let's return void in the DMA methods and let the IOMMUs assert on error. > >>>At least that will avoid surprises until someone decides they care enough about > >>>errors to touch all callers. > >>> > >>>I think silently failing a memcpy() can potentially lead to a vulnerability so > >>>I'd rather avoid that. > >> > >>No I'd rather keep the error returns, really, even if that means fixing > >>a few devices. I can look at making sure we don't pass random qemu data, > >>on error that's reasonably easy. > >> > >>assert on error means guest code can assert qemu ... not a great idea > >>but maybe we can add a warning. > > > >Why not? Guest can always just halt if it wants to anyway. > >On the other hand, warnings can fill up host logs so > >represent a security problem. > > As long as we scrub the buffers, returning an unhandled error seems okay to me. > > I've long thought we should have some sort of generic way to throw > an error and effectively pause a single device. I'm not sure how it > would work in practice though. > > Regards, > > Anthony Liguori I think we should add an API to log a message and pause the VM. Later admin can resume the VM, save it to file for debugging etc. -- MST