bus_dmamap_load_uio() and user data

[Mark Tinguely]

>  > Ahh.  I think bus_dmamap_load_uio() doesn't do deferred callbacks (i.e.
>  > mandates BUS_DMA_NOWAIT), and probably is always invoked from curthread. 
>  >  Even in the case of aio, the thread's vmspace is the effective one at the
>  >  time bus_dmamap_load_uio() would be invoked, so in practice it is safe.
>
>  I ran into ?this? problem with bus_dmamap_sync and bounce buffers while trying 
>  to do a BUS_DMASYNC_POSTREAD in interrupt context.  The sync code was trying 
>  to copy from bounce buffer to the UVA without proper context -> SEGFAULT.  I 
>  tried to move the sync to the ioctl context that is used by the userland to 
>  figure out which part of the buffer is "ready" ... this /kind of/ worked, but 
>  lead to DMA problems in ata (which I didn't yet investigate) when trying to 
>  write the buffer to disk.
>
>  I meanwhile moved to exporting a kernel buffer instead, using OBJT_SG - which 
>  is a bit more work and eats KVA, but at least on amd64 there is no shortage of 
>  that.
>
>  --
>    Max

Thank-you for the information.

If it is possible for the user context to be inactive in the DMA routines,
(as you pointed out the interrupt context) then I was thinking we would
have to:
	1) include the pmap in the bounce buffer structures in
	   busdma_load_buffer().
	2) if pmap is not kernel pmap, and not equal to the current pmap
	   then
		a) map physical page in current pmap
		b) copy from buffer using the new mapping

	   unfortunately, it is possible one of the L2 cache is VIPT which will
	   introducing page color issue and requiring every color KVAs.

	   we have the same situation in the bus dma sync routine.
	   
I will see if those with this hardware would put a test case for inactive
user pmap into the code. We would see it more often in cache syncing than
just happen to trip over bounce buffer situation.

--Mark Tinguely.