From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LCLao-0007ay-6A for qemu-devel@nongnu.org; Mon, 15 Dec 2008 17:07:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LCLam-0007ZO-88 for qemu-devel@nongnu.org; Mon, 15 Dec 2008 17:07:09 -0500 Received: from [199.232.76.173] (port=49194 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LCLam-0007ZJ-2i for qemu-devel@nongnu.org; Mon, 15 Dec 2008 17:07:08 -0500 Received: from yx-out-1718.google.com ([74.125.44.156]:41113) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LCLak-0008Nt-GI for qemu-devel@nongnu.org; Mon, 15 Dec 2008 17:07:06 -0500 Received: by yx-out-1718.google.com with SMTP id 3so1351990yxi.82 for ; Mon, 15 Dec 2008 14:07:02 -0800 (PST) Message-ID: <4946D501.4020109@codemonkey.ws> Date: Mon, 15 Dec 2008 16:06:57 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO References: <4942BDEE.7020003@codemonkey.ws> <49437EC8.6020506@redhat.com> <4943E68E.3030400@codemonkey.ws> <4944117C.6030404@redhat.com> <49442410.7020608@codemonkey.ws> <4944A1B5.5080300@redhat.com> <49455A33.207@codemonkey.ws> <49456337.4000000@redhat.com> <494591F7.3080002@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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: Andrea Arcangeli , chrisw@redhat.com, kvm@vger.kernel.org, qemu-devel@nongnu.org, Gerd Hoffmann , Avi Kivity Blue Swirl wrote: > I changed the ESP SCSI and Lance Ethernet on Sparc32 to resolve the IO > address to physical memory (see patch). ESP works (no zero copy yet), > Lance doesn't. It looks much better. Because the resolving activity is > performed in serial steps, unbounded IO vector allocation does not > happen, but we still could launch as many IO as there are free IO > vectors. > It is a good cleanup. > There are still some issues I'm not happy yet: > - handling of access violations: resolving should stop before the bad > page, the transfers should be done until that and then post error. > - bounce buffers needed for Lance byte swapping are not well designed (stack) > I think you could approach the bouncing via a map/unmap API but I'm not sure. You would need a map() function to take a virtual address which is sort of weird. That would allow you to stack them in an arbitrary fashion though. > This lead me to the thought that maybe we should not hide the bounce > buffer activity, but instead make it more explicit for the device that > needs bouncing. For the other device, the buffering or lack of it > should be opaque. > I think that's reasonable. > Also the virtual-to-physical address resolution API could be generic, > ie all resolver functions should take same parameters so that the > devices would not need to know the next higher level device. > Yes. I think this is key. The only observation I would make is that the resolution API should have some sort of release function (so map/unmap, lock/unlock, whatever). Regards, Anthony Liguori