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: Tue, 16 Dec 2008 11:48:01 -0600 Message-ID: <4947E9D1.8060007@codemonkey.ws> 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> <4947E0D1.6060704@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; 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: Avi Kivity Return-path: Received: from qw-out-2122.google.com ([74.125.92.27]:32034 "EHLO qw-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752414AbYLPRsI (ORCPT ); Tue, 16 Dec 2008 12:48:08 -0500 Received: by qw-out-2122.google.com with SMTP id 3so736501qwe.37 for ; Tue, 16 Dec 2008 09:48:06 -0800 (PST) In-Reply-To: <4947E0D1.6060704@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > Blue Swirl wrote: >>> 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? >> > > Yes. We already have two cases: > > - may do partial request: useful for block storage where requests can > be huge > - need full request: networking, where you can't send or receive half > a packet; on the other hand, packets are small (even with tso) > > You're adding a third case, always bounce, when the data undergoes a > transformation which can't happen in-place. IMHO, IOMMU translation is distinct from mapping/data transformation. I would think the IOMMU translation API would be different in that it took a physical address and returned a physical address. The IOMMU DMA API (which could transform data potentially) should return a virtual address and data a physical address. In the normal case (non-transforming IOMMU), it should just fall-through to CPU DMA API (which is just map/unmap). The PCI DMA API would normally fall through to the IOMMU DMA API. So we would have: PCI DMA map(addr): if IOMMU: return IOMMU DMA map(addr) return CPU DMA map(addr) IOMMU DMA map(addr): new_address = IOMMU translate(addr) if transform: return IOMMU byte-swap map(addr) return CPU DMA map(addr) Regards, Anthony Liguori