From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO Date: Mon, 15 Dec 2008 16:06:57 -0600 Message-ID: <4946D501.4020109@codemonkey.ws> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, Avi Kivity , Andrea Arcangeli , chrisw@redhat.com, kvm@vger.kernel.org, Gerd Hoffmann To: Blue Swirl Return-path: Received: from yw-out-2324.google.com ([74.125.46.28]:36834 "EHLO yw-out-2324.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753991AbYLOWHD (ORCPT ); Mon, 15 Dec 2008 17:07:03 -0500 Received: by yw-out-2324.google.com with SMTP id 9so1215412ywe.1 for ; Mon, 15 Dec 2008 14:07:02 -0800 (PST) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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