bus_dmamap_sync() for bounced client buffers from user address space

[Jason Harmening]

On 04/25/15 12:28, Konstantin Belousov 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.
Ah, that looks much better.  A few things though:
1) _bus_dmamap_load_ma (note the underscore) is still part of the MI/MD
interface, which we tell drivers not to use.  It looks like it's
implemented for every arch though.  Should there be a public and
documented bus_dmamap_load_ma ?
2) There is a bus_dmamap_load_ma_triv that's part of the MI interface,
but it's not documented, and it seems like it would be suboptimal in
certain cases, such as when dmar is enabled.
3) Using bus_dmamap_load_ma would mean always using physcopy for bounce
buffers...seems like the sfbufs would slow things down ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20150425/460f1e13/attachment.sig>