From owner-freebsd-current@FreeBSD.ORG Tue Jan 10 22:12:06 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6011106566B for ; Tue, 10 Jan 2012 22:12:06 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3D1DA8FC13 for ; Tue, 10 Jan 2012 22:12:05 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA07232; Wed, 11 Jan 2012 00:12:01 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RkjvF-00081i-0I; Wed, 11 Jan 2012 00:12:01 +0200 Message-ID: <4F0CB7B0.20809@FreeBSD.org> Date: Wed, 11 Jan 2012 00:12:00 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Ian Lepore References: <4F0C9D14.60705@FreeBSD.org> <1326228825.2419.22.camel@revolution.hippie.lan> <4F0CAA54.7060005@FreeBSD.org> <1326230873.2419.41.camel@revolution.hippie.lan> In-Reply-To: <1326230873.2419.41.camel@revolution.hippie.lan> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD current Subject: Re: bus dma: a flag/quirk for page zero X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 22:12:07 -0000 on 10/01/2012 23:27 Ian Lepore said the following: > On Tue, 2012-01-10 at 23:15 +0200, Andriy Gapon wrote: >> This has still some problems: >> - filter func is called for the range (lowaddr, hiaddr], that is lowadr is not >> inclusive, as such there is no way to filter page zero >> - a bounce page could still be at the physical address zero >> - and overriding the above, even worse, bounce pages are allocated in the range >> below lowaddr, so with lowaddr of zero it's impossible to have any bounce pages > > Wow, I didn't realize. That almost reads like a list of bugs in the > current busdma design. It seems especially wrong to assume that no > hardware in the world now or ever would have its range of DMA-able > addresses in the middle of its physical address space. I am tempted to agree with you here, but since this is my first encounter with the bus dma api I prefer to be cautious. I think that there should be good reasons, even if historical, why the current api is the way it is. E.g. I can not think of a good efficient way to allocate proper bounce page if the whole memory range is subject to filtering. Incremental try and error doesn't sound efficient... > I'll throw one more idea out, (because it just popped into my head, not > because I think it's the best possible idea)... Could the problems you > list be circumvented (for this situation and maybe others) with a new > flag BUS_DMA_ALWAYS_FILTER that makes the filter function run regardless > of the low/high addr values? That would add the flexibility to handle > any arbitary kinds of ranges no matter what hardware or strange > requirements come along. This should/could work, but it has the original problem that it has to be implemented for all archs separately. And also the algorithm for allocating bounce pages in this case needs to be devised. -- Andriy Gapon