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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LCe1k-0002pt-84 for qemu-devel@nongnu.org; Tue, 16 Dec 2008 12:48:12 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LCe1i-0002o6-IG for qemu-devel@nongnu.org; Tue, 16 Dec 2008 12:48:11 -0500 Received: from [199.232.76.173] (port=50082 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LCe1h-0002nD-29 for qemu-devel@nongnu.org; Tue, 16 Dec 2008 12:48:09 -0500 Received: from qw-out-1920.google.com ([74.125.92.146]:59916) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LCe1f-0000bN-UO for qemu-devel@nongnu.org; Tue, 16 Dec 2008 12:48:08 -0500 Received: by qw-out-1920.google.com with SMTP id 5so781981qwc.4 for ; Tue, 16 Dec 2008 09:48:06 -0800 (PST) Message-ID: <4947E9D1.8060007@codemonkey.ws> Date: Tue, 16 Dec 2008 11:48:01 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO 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> In-Reply-To: <4947E0D1.6060704@redhat.com> Content-Type: text/plain; charset=UTF-8; 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: Avi Kivity Cc: Andrea Arcangeli , chrisw@redhat.com, kvm@vger.kernel.org, qemu-devel@nongnu.org, Blue Swirl , Gerd Hoffmann 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