From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LCdQd-0001s4-VL for qemu-devel@nongnu.org; Tue, 16 Dec 2008 12:09:52 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LCdQa-0001oS-8B for qemu-devel@nongnu.org; Tue, 16 Dec 2008 12:09:51 -0500 Received: from [199.232.76.173] (port=45655 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LCdQa-0001oN-5d for qemu-devel@nongnu.org; Tue, 16 Dec 2008 12:09:48 -0500 Received: from mx2.redhat.com ([66.187.237.31]:37663) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LCdQZ-0000BD-EN for qemu-devel@nongnu.org; Tue, 16 Dec 2008 12:09:47 -0500 Message-ID: <4947E0D1.6060704@redhat.com> Date: Tue, 16 Dec 2008 19:09:37 +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: <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> In-Reply-To: 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: Blue Swirl Cc: Andrea Arcangeli , chrisw@redhat.com, kvm@vger.kernel.org, qemu-devel@nongnu.org, Gerd Hoffmann 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. -- error compiling committee.c: too many arguments to function