From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LCdHJ-0006VJ-CD for qemu-devel@nongnu.org; Tue, 16 Dec 2008 12:00:13 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LCdHH-0006Tv-8M for qemu-devel@nongnu.org; Tue, 16 Dec 2008 12:00:12 -0500 Received: from [199.232.76.173] (port=59914 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LCdHG-0006Tc-V4 for qemu-devel@nongnu.org; Tue, 16 Dec 2008 12:00:11 -0500 Received: from mail-bw0-f12.google.com ([209.85.218.12]:48906) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LCdHE-0006Fm-4D for qemu-devel@nongnu.org; Tue, 16 Dec 2008 12:00:09 -0500 Received: by bwz5 with SMTP id 5so6024774bwz.10 for ; Tue, 16 Dec 2008 09:00:05 -0800 (PST) Message-ID: Date: Tue, 16 Dec 2008 18:55:57 +0200 From: "Blue Swirl" Subject: Re: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO In-Reply-To: <494777E7.8050305@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <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> <494777E7.8050305@redhat.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Andrea Arcangeli , chrisw@redhat.com, kvm@vger.kernel.org, qemu-devel@nongnu.org, Gerd Hoffmann On 12/16/08, Avi Kivity wrote: > 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. Should the bouncing be something more much complex, for example negotiated between the devices? Or maybe the devices set up a transforming and non-transforming channel (which the other end should be able to transform some more) and use them as needed? In the Lance case, some of the DMA is byte swapped and some not, depending on the memory region used, some is swapped because of a global bit in a register and finally the Sparc32 DMA controller reverses the swapping.