From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LCWRP-0006sn-O6 for qemu-devel@nongnu.org; Tue, 16 Dec 2008 04:42:11 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LCWRN-0006ra-P4 for qemu-devel@nongnu.org; Tue, 16 Dec 2008 04:42:11 -0500 Received: from [199.232.76.173] (port=33007 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LCWRN-0006rQ-KZ for qemu-devel@nongnu.org; Tue, 16 Dec 2008 04:42:09 -0500 Received: from mx2.redhat.com ([66.187.237.31]:38341) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LCWRN-0004Lr-0v for qemu-devel@nongnu.org; Tue, 16 Dec 2008 04:42:09 -0500 Message-ID: <494777E7.8050305@redhat.com> Date: Tue, 16 Dec 2008 11:41:59 +0200 From: Avi Kivity 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> <4946D501.4020109@codemonkey.ws> In-Reply-To: <4946D501.4020109@codemonkey.ws> 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: Anthony Liguori Cc: Andrea Arcangeli , chrisw@redhat.com, kvm@vger.kernel.org, qemu-devel@nongnu.org, Blue Swirl , Gerd Hoffmann Anthony Liguori wrote: >> 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. > I think that's broken. iommus converts physical addresses to physical addresses (or bus addresses), possibly generating faults along the way, and depending on the iommu context. map()/unmap() converts physical/bus addresses to virtual addresses, possibly bouncing. Except for both doing conversions, they're very different. >> 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. I don't understand. It's not a device that needs bouncing, it's a particular transfer. This could be either due to the transfer targeting mmio, or due to the transfer requiring a transformation. > >> 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). Also, in order to support chaining, the input and output parameters need to be the same (both sglists). -- error compiling committee.c: too many arguments to function