From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JfzCE-0001kv-Vo for qemu-devel@nongnu.org; Sun, 30 Mar 2008 11:11:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JfzCD-0001hy-4A for qemu-devel@nongnu.org; Sun, 30 Mar 2008 11:11:46 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JfzCD-0001hj-17 for qemu-devel@nongnu.org; Sun, 30 Mar 2008 11:11:45 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JfzCC-0005eB-Jx for qemu-devel@nongnu.org; Sun, 30 Mar 2008 11:11:44 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m2UFBgsa001266 for ; Sun, 30 Mar 2008 11:11:42 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m2UFBgmW177678 for ; Sun, 30 Mar 2008 09:11:42 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m2UFBf7V024132 for ; Sun, 30 Mar 2008 09:11:42 -0600 Message-ID: <47EFADAB.5030608@us.ibm.com> Date: Sun, 30 Mar 2008 10:11:39 -0500 From: Anthony Liguori 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: 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: Blue Swirl Cc: kvm-devel@lists.sourceforge.net, Marcelo Tosatti , qemu-devel@nongnu.org, Aurelien Jarno Blue Swirl wrote: > On 3/30/08, Anthony Liguori wrote: > >> Blue Swirl wrote: >> > On 3/30/08, Anthony Liguori wrote: >> > >> >> This patch introduces a PCI DMA API and some generic code to support other DMA >> >> APIs. Two types are introduced: PhysIOVector and IOVector. A DMA API >> >> maps a PhysIOVector, which is composed of target_phys_addr_t, into an IOVector, >> >> which is composed of void *. >> >> >> > >> > 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. >> > > Devices should not need to know about the underlying buses, so they > can be used in different systems. I don't think it will be too hard for a device to support multiple buses if we have the DMA API at the bus level. In the future, the per-bus DMA API may have slight, but important differences. For instance, at some point, PCI devices will be capable of recovering from an IO fault and you'd eventually want the DMA API to reflect this for PCI. Regards, Anthony LIguori > So the translators just call > recursively next ones until we get physical memory. I would use the > opaque parameter as a pointer to each translator's own state > structures. But if you can implement this without the parameter, > great! >