From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Shbto-0001e2-ND for qemu-devel@nongnu.org; Thu, 21 Jun 2012 03:33:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Shbtj-00083D-Ur for qemu-devel@nongnu.org; Thu, 21 Jun 2012 03:33:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8714) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Shbtj-00082w-N3 for qemu-devel@nongnu.org; Thu, 21 Jun 2012 03:33:47 -0400 Date: Thu, 21 Jun 2012 10:33:38 +0300 From: "Michael S. Tsirkin" Message-ID: <20120621073338.GA31732@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1340229726.28143.200.camel@pasglop> 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: Benjamin Herrenschmidt Cc: Gerd Hoffmann , qemu-devel@nongnu.org, Anthony Liguori , David Gibson 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. > > >> Why leave pci accessors and not implement usb_memory_rw() wrappers? > > > > > > Well, "usb" is a bit too generic, ehci and ohci would each need to have > > > their own sets of wrappers. But yes, that's possible... is it really > > > worth it ? There's nothing fundamentally wrong with using the dma_* > > > accessors. > > > > So is using the pci accessors wrong? > > Not really either, I don't think it matters :-) > > > I'm not saying you should go and convert every caller of the pci_ functions, I > > just want a clear policy on what interface devices should use. > > Ideally the bus interface for the bus they sit on so they don't have to > bother digging the DMAContext and are immune to change we would do in > that area. > > Devices that mix multiple bus types however are a bit more tricky, but > so far are few, and those can use dma_* and know where to get the > DMAContext from. > > If we ever replace DMAContext with something else we can probably just > change the field to that "something else" with a very simple > search/replace on those devices (at least that's the best case :-) > > I think anything else is just no worth bothering. > > Cheers, > Ben.