From owner-freebsd-arch@FreeBSD.ORG Sun Apr 26 18:02:45 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BCE113AE for ; Sun, 26 Apr 2015 18:02:45 +0000 (UTC) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 760D010A9 for ; Sun, 26 Apr 2015 18:02:45 +0000 (UTC) Received: by oiko83 with SMTP id o83so73893885oik.1 for ; Sun, 26 Apr 2015 11:02:44 -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=rnqbSthaT/1Vc0JHz5+2PPFOazfbUncR3bsi7ooNK98=; b=h91WrfyebFwjCges2TwApNteb5n5y6xE6EEW2pEVxahix94J2vVefQP8qIn2Php5dm zVzIW+nK1gKKcYsf1Say2h7vSHOY6GZ5iUDP9hpDGExztFTaZodzhq4E8JtNDiHgMjqQ ca74RTiNepDTCKy+SO5g24Sa5+jQY8l1sjLfnjPXibWTTY5mRJKbwLHpb63w3FJSeRvf /M56Je7j7dv+vBHfahOUtpxJ96ObYm4Hc1BvVSALmIr97jTeKyzDKSeqvW6KKA31Fymj sjZhRyFXHJipcv9JYj2/3pee4Z3HRKIzXjdoZW3DmcetljIy16Fx7RbbfEYp2DCCWkKE vhLg== X-Received: by 10.60.223.228 with SMTP id qx4mr6974831oec.24.1430071364726; Sun, 26 Apr 2015 11:02:44 -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 m42sm7994785oik.3.2015.04.26.11.02.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 11:02:44 -0700 (PDT) Message-ID: <553D2890.4020107@gmail.com> Date: Sun, 26 Apr 2015 13:04:00 -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> <553BD501.4010109@gmail.com> <20150425181846.GN2390@kib.kiev.ua> <553BE12B.4000105@gmail.com> <20150425201410.GP2390@kib.kiev.ua> In-Reply-To: <20150425201410.GP2390@kib.kiev.ua> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="eCCgoIbMufOXxfvxMFPjB42fodthGCmE7" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Sun, 26 Apr 2015 18:02:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eCCgoIbMufOXxfvxMFPjB42fodthGCmE7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 04/25/15 15:14, Konstantin Belousov wrote: > On Sat, Apr 25, 2015 at 01:47:07PM -0500, Jason Harmening wrote: >> On 04/25/15 13:18, Konstantin Belousov wrote: >>> On Sat, Apr 25, 2015 at 12:55:13PM -0500, Jason Harmening wrote: >>>> 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 ? >>> Might be yes. But at least one consumer of the KPI must appear befor= e >>> the facility is introduced. >> Could some of the GART/GTT code consume that? > Do you mean, by GEM/GTT code ? Indeed, this is interesting and probabl= y > workable suggestion. I thought that I would need to provide a special > interface from DMAR for the GEM, but your proposal seems to fit. Still= , > an issue is that the Linux code is structured significantly different, > and this code, although isolated, is significant divergent from the > upstream. Yes, GEM/GTT. I know it would be useful for i915, maybe other drm2 drivers too. > >>>> 3) Using bus_dmamap_load_ma would mean always using physcopy for bou= nce >>>> buffers...seems like the sfbufs would slow things down ? >>> For amd64, sfbufs are nop, due to the direct map. But, I doubt that >>> we can combine bounce buffers and performance in the single sentence.= >> In fact the amd64 implementation of uiomove_fromphys doesn't use sfbuf= s >> at all thanks to the direct map. sparc64 seems to avoid sfbufs as muc= h >> as possible too. I don't know what arm64/aarch64 will be able to use.= =20 >> Those seem like the platforms where bounce buffering would be the most= >> likely, along with i386 + PAE. They might still be used on 32-bit >> platforms for alignment or devices with < 32-bit address width, but th= en >> those are likely to be old and slow anyway. >> >> I'm still a bit worried about the slowness of waiting for an sfbuf if >> one is needed, but in practice that might not be a big issue. >> I noticed the following in vm_map_delete, which is called by sys_munmap: =20 2956 * Wait for wiring or unwiring of an entry to compl= ete. 2957 * Also wait for any system wirings to disappear on= 2958 * user maps. 2959 */ 2960 if ((entry->eflags & MAP_ENTRY_IN_TRANSITION) !=3D = 0 || 2961 (vm_map_pmap(map) !=3D kernel_pmap && 2962 vm_map_entry_system_wired_count(entry) !=3D 0))= { =2E.. 2970 (void) vm_map_unlock_and_wait(map, 0); It looks like munmap does wait on wired pages (well, system-wired pages, = not mlock'ed pages). The system-wire count on the PTE will be non-zero if vslock/vm_map_wire(.= =2E.VM_MAP_WIRE_SYSTEM...) was called on it. Does that mean UIO_USERSPACE dmamaps are actually safe from getting the U= VA taken out from under them? Obviously it doesn't make bcopy safe to do in the wrong process context, = but that seems easily fixable. --eCCgoIbMufOXxfvxMFPjB42fodthGCmE7 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 iQF8BAEBCgBmBQJVPSiQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwAAoJELufi/mShB0ba7gIAIcGtzGRq1R1W/S8AoR2qTCi JY9p/fLrD4i1kmiOmcI2hnfBa9UbFLmUGOJnlnrNifQfhY3vnw/IPHhO6zlQW8Jp llSh6eBiq2lb59+ptA0VLDE33mOzIL2/ZYBVm7EmavGirKVEBtbGLLtCw20ZwiQz HiRj1cXoppwYyt6xrl1OtbQs9jZNqURvdIwVa2NkwVKZftwqtGv4a5UXJXNr08U3 wbi9niaylcAjwpBlxheemBkC1V0m5QtVvAOSbxMsKwlxOGgMJztnQrksJOWgVvIH qm4FZeKGOUSSzswfd8l0WWMzkBi4mYdFo6JhRpP3lWYmWow+uBTe0+Y9RU3RxBw= =nb6L -----END PGP SIGNATURE----- --eCCgoIbMufOXxfvxMFPjB42fodthGCmE7--