bus_dmamap_sync() for bounced client buffers from user address space

[Svatopluk Kraus]

On Wed, Apr 29, 2015 at 12:27 AM, John Baldwin <jhb at freebsd.org> wrote:
> On Tuesday, April 28, 2015 12:10:43 PM Adrian Chadd wrote:
>> On 28 April 2015 at 09:19, Warner Losh <imp at bsdimp.com> wrote:
>> >
>> >> On Apr 28, 2015, at 7:40 AM, John Baldwin <jhb at FreeBSD.org> wrote:
>> >>
>> >>> I believe UIO_USERSPACE is almost unused, it might be there for some
>> >>> obscure (and buggy) driver.
>> >>
>> >> I believe it was added (and only ever used) in crypto drivers, and that they
>> >> all did bus_dma operations in the context of the thread that passed in the
>> >> uio.  I definitely think it is fragile and should be replaced with something
>> >> more reliable.
>> >
>> > Fusion I/O’s SDK used this trick to allow mapping of userspace buffers down
>> > into the block layer after doing the requisite locking / pinning / etc of the buffers
>> > into memory. That’s if memory serves correctly (the SDK did these things, I can’t
>> > easily check on that detail since I’m no longer at FIO).
>>
>> This is a long-standing trick. physio() does it too,
>> aio_read/aio_write does it for direct block accesses. Now that pbufs
>> aren't involved anymore, it should scale rather well.
>>
>> So I'd like to see more of it in the kernel and disk/net APIs and drivers.
>
> aio_read/write jump through gross hacks to create dedicated kthreads that
> "borrow" the address space of the requester.  The fact is that we want to
> make unmapped I/O work in the general case and the same solutions for
> temporary mappings for that can be reused to temporarily map the wired
> pages backing a user request when needed.  Reusing user mappings directly
> in the kernel isn't really the way forward.
>


If using unmapped buffers is the way we will take to play with user
space buffers, then:

(1) DMA clients, which support DMA for user space buffers, must use
some variant of _bus_dmamap_load_phys(). They must wire physical pages
in system anyway.
(2) Maybe some better way how to temporarily allocate KVA for unmapped
buffers should be implemented.
(3) DMA clients which already use _bus_dmamap_load_uio() with
UIO_USERSPACE must be reimplemented or made obsolete.
(4) UIO_USERSPACE must be off limit in _bus_dmamap_load_uio() and man
page should be changed according to it.
(5) And pmap can be deleted from struct bus_dmamap and all functions
which use it as argument. Only kernel pmap will be used in DMA
framework.

Did I miss out something?


> --
> John Baldwin