bus_dmamap_sync() for bounced client buffers from user address space

[Svatopluk Kraus]

On Sat, Apr 25, 2015 at 7:28 PM, Konstantin Belousov
<kostikbel at gmail.com> wrote:
> On Sat, Apr 25, 2015 at 12:07:29PM -0500, Jason Harmening wrote:
>>
>> On 04/25/15 11:34, Konstantin Belousov wrote:
>> > I believe UIO_USERSPACE is almost unused, it might be there for some
>> > obscure (and buggy) driver.
>> It may be nearly unused, but we still document it in busdma.9, and we
>> still explicitly check for it when setting the pmap in
>> _bus_dmamap_load_uio.  If it's not safe to use, then it's not OK for us
>> to do that.
>> We need to either a) remove support for it by adding a failure/KASSERT
>> on UIO_USERSPACE in _busdmamap_load_uio() and remove the paragraph on it
>> from busdma.9, or b) make it safe.
>>
>> I'd be in favor of b), because I think it is still valid to support some
>> non-painful way of using DMA with userspace buffers.  Right now, the
>> only safe way to do that seems to be:
>> 1) vm_fault_quick_hold_pages
>> 2) kva_alloc
>> 3) pmap_qenter
>> 4) bus_dmamap_load
> 1. vm_fault_quick_hold
> 2. bus_dmamap_load_ma
>
>>
>> That seems both unnecessarily complex and wasteful of KVA space.
>>
> The above sequence does not need a KVA allocation.
>
>

But if the buffer bounces, then some KVA must be allocated temporarily
for physcopyin/physcopyout.

FYI, we are in the following situation in ARM arch. (1) The DMA in not
cache coherent, and (2) cache maintainance operations are done on
virtual addresses. It means that cache maintainance must be done for
cached memory. Moreover, it must be done even for unmapped buffers and
they must be mapped for that.

Thus it could be of much help if we can used UVA for that if context is correct.