From owner-freebsd-arch@FreeBSD.ORG Sat Apr 25 17:53:58 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B159D1CD for ; Sat, 25 Apr 2015 17:53:58 +0000 (UTC) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6ED65194A for ; Sat, 25 Apr 2015 17:53:58 +0000 (UTC) Received: by oign205 with SMTP id n205so62710532oig.2 for ; Sat, 25 Apr 2015 10:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=zfrSQAiZztFEWS4GNzxodqQ+QpYS/QjEVLYB8Iel53s=; b=z+MMXalU8XqNmc6VGvvqN0uBl/OBq8rc9fCP3QqQ7jErUf2DJLFkoeb7QCR5y4f+nn K5C6QnJsSkZ43o1qIBEJlPl/2UMmTWGb6Snm8oDYYrfmq563prw2CXcdLkaHnBmZXZdn 02kbUYtXLEyef6Juw83jR8aDNLFXgL+gWk6NOd8BYC3cL2lr9yE9oDevwM1tECyrEXBx UuZBBSuENGvDeMGEsGL/zX9YCUgQE7CSqYUxSQPSC4SnunVZbqA+eT+7CyEarBLUctfb oKzfXrYatZAt2XB1LJ2FqlEkCwia4wIMPW63mgeHlV5LJALZy4CFSizscm3Agj75EKCh 4pGQ== X-Received: by 10.202.46.81 with SMTP id u78mr3363538oiu.54.1429984437895; Sat, 25 Apr 2015 10:53:57 -0700 (PDT) Received: from corona.austin.rr.com (cpe-72-177-6-10.austin.res.rr.com. [72.177.6.10]) by mx.google.com with ESMTPSA id c3sm7652186obo.5.2015.04.25.10.53.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Apr 2015 10:53:57 -0700 (PDT) Message-ID: <553BD501.4010109@gmail.com> Date: Sat, 25 Apr 2015 12:55:13 -0500 From: Jason Harmening User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Konstantin Belousov CC: Svatopluk Kraus , FreeBSD Arch Subject: Re: bus_dmamap_sync() for bounced client buffers from user address space References: <20150425094152.GE2390@kib.kiev.ua> <553B9E64.8030907@gmail.com> <20150425163444.GL2390@kib.kiev.ua> <553BC9D1.1070502@gmail.com> <20150425172833.GM2390@kib.kiev.ua> In-Reply-To: <20150425172833.GM2390@kib.kiev.ua> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UoMawm07iWViiabtCn5TNOBAjbLNEqJQ7" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 17:53:58 -0000 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--