bus_dmamap_sync() for bounced client buffers from user address space

[Konstantin Belousov]

On Wed, Apr 29, 2015 at 05:09:18PM +0200, Svatopluk Kraus wrote:
> On Wed, Apr 29, 2015 at 3:20 PM, Konstantin Belousov
> <kostikbel at gmail.com> wrote:
> > On Wed, Apr 29, 2015 at 12:22:19PM +0200, Svatopluk Kraus wrote:
> >> 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.
> > No, vm_fault_quick_hold_pages() + bus_dmamap_load_ma().
> > Or yes, if you count bus_dmamap_load_ma() as a variant of _load_phys().
> > I do not.
> 
> There are only two basic functions in MD implementations which all
> other functions call: _bus_dmamap_load_phys() and
> _bus_dmamap_load_buffer() as a synonym for unmapped buffers and mapped
> ones. Are you saying that bus_dmamap_load_ma() should be some third
> kind?
It is.

On the VT-d backed x86 busdma, load_ma() is the fundamental function,
which is called both by _load_buffer() and _load_phys().  This is not
completely true, the real backstage worker is called _load_something(),
but it differs from _load_ma() only by taking casted tag and map.

On the other hand, the load_ma_triv() wrapper implements _load_ma()
using load_phys() on architectures which do not yet provide native
_load_ma(), or where native _load_ma() does not make sense.

> 
> >
> >> (2) Maybe some better way how to temporarily allocate KVA for unmapped
> >> buffers should be implemented.
> > See some other mail from me about non-blocking sfbuf allocator with
> > callback.
> 
> This small list was meant as summary. As I saw your emails in this
> thread, I added this point . I did not get that it's already in source
> tree.
No, it is not.  I stopped working on it during the unmapped i/o work,
after I realized that there is no much interest from the device drivers
authors.  Nobody cared about drivers like ATA PIO.

Now, with the new possible use for the non-blocking sfbuf allocator,
it can be revived.

> 
> >
> >> (3) DMA clients which already use _bus_dmamap_load_uio() with
> >> UIO_USERSPACE must be reimplemented or made obsolete.
> > Yes.
> >
> >> (4) UIO_USERSPACE must be off limit in _bus_dmamap_load_uio() and man
> >> page should be changed according to it.
> > Yes.
> 
> 
> Hmm, I think that for the beginning, _bus_dmamap_load_uio() for
> UIO_USERSPACE  can be hacked to use bus_dmamap_load_ma(). Maybe with
> some warning to force users of old clients to reimplement them.
Also it would be a good test for my claim that
vm_fault_quick_hold_pages() + bus_dmamap_load_ma() is all what is
needed.

> 
> 
> >
> >> (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.
> > Probably yes.
> >