NVIDIA FreeBSD kernel feature requests

[John Baldwin]

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 at wolf.nvidia.com>
> >>             Christian Zander <czander at nvidia.com> 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