Date: Wed, 29 Apr 2015 19:54:32 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Svatopluk Kraus <onwahe@gmail.com> Cc: John Baldwin <jhb@freebsd.org>, Adrian Chadd <adrian@freebsd.org>, Warner Losh <imp@bsdimp.com>, Jason Harmening <jason.harmening@gmail.com>, freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: bus_dmamap_sync() for bounced client buffers from user address space Message-ID: <20150429165432.GN2390@kib.kiev.ua> In-Reply-To: <CAFHCsPWjEFBF%2B-7SR7EJ3UHP6oAAa9xjbu0CbRaQvd_-6gKuAQ@mail.gmail.com> References: <CAFHCsPXMjge84AR2cR8KXMXWP4kH2YvuV_uqtPKUvn5C3ygknw@mail.gmail.com> <38574E63-2D74-4ECB-8D68-09AC76DFB30C@bsdimp.com> <CAJ-VmomqGkEFVauya%2BrmPGcD_-=Z-mmg1RSDf1D2bT_DfwPBGA@mail.gmail.com> <1761247.Bq816CMB8v@ralph.baldwin.cx> <CAFHCsPX9rgmCAPABct84a000NuBPQm5sprOAQr9BTT6Ev6KZcQ@mail.gmail.com> <20150429132017.GM2390@kib.kiev.ua> <CAFHCsPWjEFBF%2B-7SR7EJ3UHP6oAAa9xjbu0CbRaQvd_-6gKuAQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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. > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150429165432.GN2390>