From owner-freebsd-current@FreeBSD.ORG Tue Jan 10 21:15:08 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 3487F1065670 for ; Tue, 10 Jan 2012 21:15:08 +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 7B44B8FC13 for ; Tue, 10 Jan 2012 21:15:07 +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 XAA06662; Tue, 10 Jan 2012 23:15: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 1Rkj25-0007yz-1u; Tue, 10 Jan 2012 23:15:01 +0200 Message-ID: <4F0CAA54.7060005@FreeBSD.org> Date: Tue, 10 Jan 2012 23:15: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> In-Reply-To: <1326228825.2419.22.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 21:15:08 -0000 on 10/01/2012 22:53 Ian Lepore said the following: > On Tue, 2012-01-10 at 22:18 +0200, Andriy Gapon wrote: >> >> Some hardware interfaces may reserve a special meaning for a (physical) memory >> address value of zero. One example is the OHCI specification where a zero value >> in CurrentBufferPointer doesn't mean a physical address, but has a reserved >> meaning. To be honest I don't have another example :) but don't preclude its >> existence. >> >> To deal with this peculiarity we could use a special flag/quirk that would >> instruct the bus dma code to never use the page zero for communication with the >> hardware. >> Here's a proof of concept patch that implements the idea: >> http://people.freebsd.org/~avg/usb-dma-pagezero.diff >> >> Some concerns: >> - not sure if BUS_DMA_NO_PAGEZERO is the best name for the flag >> - the patch implements the flag only for x86 at the moment >> - usb code uses the flag regardless of the actual controller type >> >> What do you think? > > I think another way to handle this, one that doesn't require modifying > the busdma_machdep implementation for every architecture, would be for > usb_dma_tag_create() to set lowaddr to zero and provide a filter func > that filters based on both the value zero and the expression currently > being passed as lowaddr. At least, I think that's how the filterfunc > stuff is supposed to work, I've never actually coded a busdma filter. 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 > This has the advantage I call "locality of strangeness." If only the > OHCI hardware needs this strange processing, and it seems like in the > future this strangeness will still be more the exception than the rule, > then the strangeness is best kept close to the place where it's needed, > rather than being spread out all over the place (lots of machdep > places). -- Andriy Gapon