From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42775) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S1lMg-00056i-OQ for qemu-devel@nongnu.org; Sun, 26 Feb 2012 16:10:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S1lMe-0001wv-2b for qemu-devel@nongnu.org; Sun, 26 Feb 2012 16:10:42 -0500 Received: from mail-ee0-f45.google.com ([74.125.83.45]:46074) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S1lMd-0001wp-Ry for qemu-devel@nongnu.org; Sun, 26 Feb 2012 16:10:40 -0500 Received: by eeit10 with SMTP id t10so1426137eei.4 for ; Sun, 26 Feb 2012 13:10:38 -0800 (PST) Sender: Eduard - Gabriel Munteanu Date: Sun, 26 Feb 2012 23:09:38 +0200 From: Eduard - Gabriel Munteanu Message-ID: <20120226210938.GA3671@localhost> References: <1330054063-16860-1-git-send-email-david@gibson.dropbear.id.au> <1330054063-16860-5-git-send-email-david@gibson.dropbear.id.au> <20120226100449.GB11324@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120226100449.GB11324@redhat.com> Subject: Re: [Qemu-devel] [PATCH 4/8] Add universal DMA helper functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Joerg Rodel , Richard Henderson , qemu-devel@nongnu.org, anthony@codemonkey.ws, David Gibson On Sun, Feb 26, 2012 at 12:04:49PM +0200, Michael S. Tsirkin wrote: > On Fri, Feb 24, 2012 at 02:27:39PM +1100, David Gibson wrote: > > Not that long ago, every device implementation using DMA directly > > accessed guest memory using cpu_physical_memory_*(). This meant that > > adding support for a guest visible IOMMU would require changing every > > one of these devices to go through IOMMU translation. > > > > Shortly before qemu 1.0, I made a start on fixing this by providing > > helper functions for PCI DMA. These are currently just stubs which > > call the direct access functions, but mean that an IOMMU can be > > implemented in one place, rather than for every PCI device. > > > > Clearly, this doesn't help for non PCI devices, which could also be > > IOMMU translated on some platforms. It is also problematic for the > > devices which have both PCI and non-PCI version (e.g. OHCI, AHCI) - we > > cannot use the the pci_dma_*() functions, because they assume the > > presence of a PCIDevice, but we don't want to have to check between > > pci_dma_*() and cpu_physical_memory_*() every time we do a DMA in the > > device code. > > > > This patch makes the first step on addressing both these problems, by > > introducing new (stub) dma helper functions which can be used for any > > DMA capable device. > > > > These dma functions take a DMAContext *, a new (currently empty) > > variable describing the DMA address space in which the operation is to > > take place. NULL indicates untranslated DMA directly into guest > > physical address space. The intention is that in future non-NULL > > values will given information about any necessary IOMMU translation. > > > > DMA using devices must obtain a DMAContext (or, potentially, contexts) > > from their bus or platform. For now this patch just converts the PCI > > wrappers to be implemented in terms of the universal wrappers, > > converting other drivers can take place over time. > > > > Cc: Michael S. Tsirkin > > Cc: Joerg Rodel > > Cc: Eduard - Gabriel Munteanu > > Cc: Richard Henderson > > > > Signed-off-by: David Gibson > > I'm a bit confused with all the stubbing going on. > Is this the final form of the pci_* functions or just > a stub? If the final form, we probably should just > open-code them - they don't buy us much. > If not, let's add a comment? > It is a stub. The final form needs to deal with address translation, permissions checking and invalidating memory maps. [snip] Eduard