From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPNCi-00081V-S2 for qemu-devel@nongnu.org; Tue, 20 Jan 2009 15:28:08 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPNCi-00080Y-59 for qemu-devel@nongnu.org; Tue, 20 Jan 2009 15:28:08 -0500 Received: from [199.232.76.173] (port=48658 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPNCh-00080K-Q6 for qemu-devel@nongnu.org; Tue, 20 Jan 2009 15:28:07 -0500 Received: from mx2.redhat.com ([66.187.237.31]:35315) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LPNCh-0003MJ-9d for qemu-devel@nongnu.org; Tue, 20 Jan 2009 15:28:07 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n0KKS61a024382 for ; Tue, 20 Jan 2009 15:28:06 -0500 Message-ID: <497633C9.1050902@redhat.com> Date: Tue, 20 Jan 2009 22:27:53 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API References: <1232308399-21679-1-git-send-email-avi@redhat.com> <1232308399-21679-2-git-send-email-avi@redhat.com> <18804.34053.211615.181730@mariner.uk.xensource.com> <4974943B.4020507@redhat.com> <18804.44271.868488.32192@mariner.uk.xensource.com> <4974B82F.9020805@redhat.com> <20090119182502.GA2080@shareable.org> <4974C9BA.1050803@redhat.com> <18805.58460.230350.875145@mariner.uk.xensource.com> <49760D1C.3020202@redhat.com> <20090120180819.GA27464@shareable.org> In-Reply-To: <20090120180819.GA27464@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; 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: qemu-devel@nongnu.org Jamie Lokier wrote: > Linux itself had some issues with _its_ DMA API recently: people have > been writing drivers using the Linux DMA API making broken assumptions > that happen to work on x86, and work some of the time on other > architectures. These things don't show up during driver tests, and > are very difficult to track down later. I suspect "overwrites the > remaining buffer with randomness/zeros but only under bounce-buffer > conditions" will be similarly unlikely to trigger, and very difficult > to track down if it causes a problem anywhere. > This reminds me -- Gleb pointed out that Linux itself bounces some DMA operations, and will copy the entire range. So Linux itself doesn't satisfy these requirements. > The recent solution in Linux is to add some debugging options which > check it's used correctly, even on x86. > > Here's a final thought, to do with performance: > > e1000, configured for jumbo frames, receives logs of small packets, > and the DMA subsystem has to bounce-copy the data for some reason (Ian > suggested maybe always doing that with Xen for DMA to guest RAM?) > > Without a length passed to unmap, won't it copy 65536 bytes per packet > (most from cold cache) because that's the amount set up for DMA to > receive from /dev/tap, instead of 256 or 1514 bytes per packet which > is their actual size? > It will. If we bounce. We'll never bounce in real life. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.