Andrew Gallatin wrote: > Mark Johnson writes: > > > > > > Andrew Gallatin wrote: > > > I was just reading up on mmap in Solaris drivers, and I'm > > > afraid I may have a problem...: > > > > > > I need to allocate and map into userspace a bunch of 128KB buffers. > > > The buffers need to be physically contiguous in DMA space, and > > > virtually contiguous in userspace. This has to run on amd64, so I > > > can't use an IOMMU to make discontiguous 4KB pages contiguous. > > > > > > According to devmap_umemem_setup(9f), I'm supposed to use > > > devmap_umem_setup() for kernel memory, and I need to pass a > > > ddi_umem_cookie_t. The ddi_umem_cookie_t means (I think) that I must > > > allocate the memory via ddi_umem_alloc(), and I don't think that will > > > allocate anything larger than a single page physically contiguous. > > > > > > Is there any way I can use ddi_dma_alloc_mem_alloc() (or something > > > else) to get 128KB physically contiguous and map that out? > > > > > > Or.... Is it still acceptable to supply a cb_mmap() and use the nice, > > > simple, straightforward old way of returning a page frame number? > > > > Unfortunately, there isn't a way to do this with the DDI > > today. We have an RFE out there to fix it... > > > > You can do something similar to xsvc_umem_cookie_alloc()/ > > xsvc_umem_cookie_free(). e.g. pass in a kva returned > > from ddi_dma_mem_alloc(). > > > > The RFE will probably create > ddi_umem_cookie_alloc()/ddi_umem_cookie_free(). > > > > disclaimers: doing this is totally unsupported, could > > break in a new solaris revision, or even patch. > > Thanks, but the disclaimer is kind of scary :)
Yes. :-) I would be surprised if it broke, but it's always possible. So it has to be said ;-) > Will the old hat_getkpfnum based mmap entry point still work? Not sure what your talking about. If your talking about segmap, that doesn't support PAE (in a 32-bit kernel). Also, hat_getkpfnum() is going to be removed one of these days. MRJ _______________________________________________ driver-discuss mailing list driver-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/driver-discuss
