> You should use the pmap from the thread in the uio structure. Similar to > this from the x86 bus_dma code: > > if (uio->uio_segflg == UIO_USERSPACE) { > KASSERT(uio->uio_td != NULL, > ("bus_dmamap_load_uio: USERSPACE but no proc")); > pmap = vmspace_pmap(uio->uio_td->td_proc->p_vmspace); > } else > pmap = NULL; > > Later when doing VA -> PA conversions the code does this: > > if (pmap) > paddr = pmap_extract(pmap, vaddr); > else > paddr = pmap_kextract(vaddr); >
We do that, but I notice that all the architecture that implement bounce buffers assume the VA is in the current map. Most of the addresses are KVA, but bus_dmamap_load_uio() can be in the user space. I was wondering about the sequence: bus_dmamap_load_uio() user space dma_load_buffer() add bounce page save UVA (in caller user map) later: bus_dma_sync copies bounce buffer from saved UVA. <- here is my concern. The user pmap is not remembered use current pmap. Since the bounce buffer copy routines have been running in other architectures for years without corruption, I was wondering we can safely assume that the dma sync is running in the same thread/address space as the bus_dmamap_load_uio call. I was hoping you would say, don't worry the scheduler would always reload the same thread to execute the dma sync code ... Thank-you, --Mark Tinguely _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"