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>