Date: Fri, 8 Jan 2010 08:14:36 -0600 (CST) From: Mark Tinguely <tinguely@casselton.net> To: freebsd-hackers@freebsd.org, jhb@freebsd.org Cc: tinguely@casselton.net Subject: Re: bus_dmamap_load_uio() and user data Message-ID: <201001081414.o08EEaBM053148@casselton.net> In-Reply-To: <201001080833.49246.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201001081414.o08EEaBM053148>