From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JfyqZ-0007Bf-Qt for qemu-devel@nongnu.org; Sun, 30 Mar 2008 10:49:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JfyqY-0007BH-Cr for qemu-devel@nongnu.org; Sun, 30 Mar 2008 10:49:23 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JfyqY-0007BE-9A for qemu-devel@nongnu.org; Sun, 30 Mar 2008 10:49:22 -0400 Received: from bzq-179-150-194.static.bezeqint.net ([212.179.150.194] helo=il.qumranet.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JfyqX-0001p8-O7 for qemu-devel@nongnu.org; Sun, 30 Mar 2008 10:49:22 -0400 Message-ID: <47EFA86F.8020905@qumranet.com> Date: Sun, 30 Mar 2008 17:49:19 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/6] PCI DMA API References: <1206827760-4566-1-git-send-email-aliguori@us.ibm.com> <1206827760-4566-2-git-send-email-aliguori@us.ibm.com> <47EFA769.7090201@us.ibm.com> In-Reply-To: <47EFA769.7090201@us.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Blue Swirl , kvm-devel@lists.sourceforge.net, Marcelo Tosatti , Aurelien Jarno Anthony Liguori wrote: >> >> This looks like it wouldn't scale to handle the Sparc systems. There >> we want to make more translation steps from DVMA addresses to physical >> in DMA controller and IOMMU and only in the final stage to void *. To >> handle this, probably there should be an opaque parameter and some way >> to register the translation function. Otherwise the API looks OK. >> > > I think having the PCI DMA API translate PhysIOVector => PhysIOVector > would help. Then it becomes pretty easy to just call the DMA > controller for additional translation from the IOMMU. > > Does that sound right? I don't quite understand what role the opaque > parameter would serve. > State for the dma controller. I think Blue is calling for chaining of dma mappings, no? Something similar is being proposed for the Linux dma api. -- error compiling committee.c: too many arguments to function