Date: Sat, 25 Apr 2015 12:55:13 -0500 From: Jason Harmening <jason.harmening@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Svatopluk Kraus <onwahe@gmail.com>, FreeBSD Arch <freebsd-arch@freebsd.org> Subject: Re: bus_dmamap_sync() for bounced client buffers from user address space Message-ID: <553BD501.4010109@gmail.com> In-Reply-To: <20150425172833.GM2390@kib.kiev.ua> References: <CAFHCsPXMjge84AR2cR8KXMXWP4kH2YvuV_uqtPKUvn5C3ygknw@mail.gmail.com> <CAM=8qan-4SbKJaddrfkv=HG3n%2BHaOPDL5MEPS9DoaTvnhrJPZQ@mail.gmail.com> <20150425094152.GE2390@kib.kiev.ua> <553B9E64.8030907@gmail.com> <20150425163444.GL2390@kib.kiev.ua> <553BC9D1.1070502@gmail.com> <20150425172833.GM2390@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UoMawm07iWViiabtCn5TNOBAjbLNEqJQ7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 u= s >> 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 so= me >> 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 ? --UoMawm07iWViiabtCn5TNOBAjbLNEqJQ7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVO9UBXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwAAoJELufi/mShB0bd1cH/RxJiZ/8/3BR+A1ZUFzUXISN lygdgF/0ZYfHKk0LsRgbWcWKCWgThdgRBFn31714DiI2ZqZfkrfVzEHkeL6XoCFF Tp3Zzil4fvMqmnN/RKtD3vapw5WNZR4Qi6AQuz+vIGZ7hw2Dv71uj4MugbyU5w9t LjAcZEX8M6173itq1JtegBVCqmgQYl0stYtF5nu3u6HmuEMl2m2o9Lyo8eVpoSe3 P/MFtMHwYWaW9kcs0Z0x2hW2bHkLYYZ8QgSs93DaEo6UEtkznKCforPEE4lZvezV yZ8wlzqK73zRDpwjrTqgTsUF7bF6P/CPZSyZENMXlupsSZiahVLy1z2VliwV0c4= =6S8y -----END PGP SIGNATURE----- --UoMawm07iWViiabtCn5TNOBAjbLNEqJQ7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?553BD501.4010109>