From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO Date: Tue, 16 Dec 2008 11:41:59 +0200 Message-ID: <494777E7.8050305@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Blue Swirl , qemu-devel@nongnu.org, Andrea Arcangeli , chrisw@redhat.com, kvm@vger.kernel.org, Gerd Hoffmann To: Anthony Liguori Return-path: Received: from mx2.redhat.com ([66.187.237.31]:55935 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752172AbYLPJmK (ORCPT ); Tue, 16 Dec 2008 04:42:10 -0500 In-Reply-To: <4946D501.4020109@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: 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