From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 6 03:45:41 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C27C16A4DA for ; Thu, 6 Jul 2006 03:45:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E41A43D46 for ; Thu, 6 Jul 2006 03:45:40 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k663jSFo005135; Wed, 5 Jul 2006 23:45:29 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Sam Leffler Date: Wed, 5 Jul 2006 23:42:28 -0400 User-Agent: KMail/1.9.1 References: <20060629111231.GA692@wolf.nvidia.com> <200607051211.58386.jhb@freebsd.org> <44AC4BAC.4040105@errno.com> In-Reply-To: <44AC4BAC.4040105@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607052342.29273.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Wed, 05 Jul 2006 23:45:29 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1586/Wed Jul 5 15:22:07 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: freebsd-hackers@freebsd.org, czander@nvidia.com Subject: Re: NVIDIA FreeBSD kernel feature requests X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2006 03:45:41 -0000 On Wednesday 05 July 2006 19:30, Sam Leffler wrote: > John Baldwin wrote: > > On Monday 03 July 2006 00:02, M. Warner Losh wrote: > >> In message: <20060629111231.GA692@wolf.nvidia.com> > >> Christian Zander writes: > >> : This summary makes an attempt to describe the kernel interfaces needed by > >> : the NVIDIA FreeBSD i386 graphics driver to achieve feature parity with > >> : the Linux/Solaris graphics drivers, and/or required to make support for > >> : the FreeBSD amd64 platform feasible. It also describes some of the > >> : technical difficulties encountered by NVIDIA during the FreeBSD i386 > >> : graphics driver's development, how these problems have been worked around > >> : and what could be done to solve them better. > >> > >> Thank you for taking the time to let us know how we might make the > >> system better. > >> > >> : The NVIDIA graphics driver needs to be able to create uncached kernel > >> : and user mappings of I/O memory, such as NVIDIA GPU registers. The > >> : FreeBSD kernel does not currently provide the interfaces necessary to > >> : specify the memory type when creating such mappings, which makes it > >> : difficult for the NVIDIA graphics driver to guarantee that the correct > >> : memory type is selected. > >> > >> Is this via the bus_alloc_resource interface? Is uncached kernel > >> memory different than non-prefetchable memory? If so, please specify > >> how it is different. If not, then we have an interface that will do > >> what you want, except it is only implemented for cardbus and would > >> need to be implemented for pci pci and pci host bridges. Would having > >> better functionality here help? I noticed it wasn't on the task list... > > > > This isn't an issue of how the memory is mapped in the PCI-PCI bridge where > > non-prefetchable is used to keep the bridge from prefetching things, but as > > to how the memory is mapped in the CPU itself. Also, I've seen mention of > > using bus_dma, etc. One of the problems is our current bus APIs have a very > > limited view of caching "modes". E.g. here you mention overloading > > non-prefetchable to get a UC mapping. In bus_dma(9) we have the COHERENT > > flag to UC rather than a WB mapping. Neither of these API's allow for, say, > > WC (Write-Combining) mappings. :) Other OS's such as Windows and OS X allow > > you to explicitly specify what type of cache "mode" you want for a mapping. > > > > As we've discussed privately, bus_dma is the right api for drivers to > use. If it doesn't do what he needs then we need to extend it. Drivers > should not be groveling around inside the vm system. I don't disagree, but my point is that the APIs do need extending. Look at it this way. The current changes are to provide a way so nvidia can call pmap_foo() functions rather than modifying PTE's and the PAT MSR's directly. This is progress. :) -- John Baldwin