Date: Wed, 29 Apr 2015 12:22:19 +0200 From: Svatopluk Kraus <onwahe@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: Adrian Chadd <adrian@freebsd.org>, Warner Losh <imp@bsdimp.com>, Konstantin Belousov <kostikbel@gmail.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: <CAFHCsPX9rgmCAPABct84a000NuBPQm5sprOAQr9BTT6Ev6KZcQ@mail.gmail.com> In-Reply-To: <1761247.Bq816CMB8v@ralph.baldwin.cx> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 29, 2015 at 12:27 AM, John Baldwin <jhb@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@bsdimp.com> wrote: >> > >> >> On Apr 28, 2015, at 7:40 AM, John Baldwin <jhb@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 th= at they >> >> all did bus_dma operations in the context of the thread that passed i= n the >> >> uio. I definitely think it is fragile and should be replaced with so= mething >> >> more reliable. >> > >> > Fusion I/O=E2=80=99s 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=E2=80=99s if memory serves correctly (the SDK did th= ese things, I can=E2=80=99t >> > easily check on that detail since I=E2=80=99m 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 driver= s. > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPX9rgmCAPABct84a000NuBPQm5sprOAQr9BTT6Ev6KZcQ>