From owner-freebsd-arch@FreeBSD.ORG Wed Apr 29 16:54:39 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 A720A88B; Wed, 29 Apr 2015 16:54:39 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 313EB197D; Wed, 29 Apr 2015 16:54:39 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t3TGsW8P016999 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 29 Apr 2015 19:54:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t3TGsW8P016999 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t3TGsWpE016998; Wed, 29 Apr 2015 19:54:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 29 Apr 2015 19:54:32 +0300 From: Konstantin Belousov To: Svatopluk Kraus Cc: John Baldwin , Adrian Chadd , Warner Losh , Jason Harmening , freebsd-arch Subject: Re: bus_dmamap_sync() for bounced client buffers from user address space Message-ID: <20150429165432.GN2390@kib.kiev.ua> References: <38574E63-2D74-4ECB-8D68-09AC76DFB30C@bsdimp.com> <1761247.Bq816CMB8v@ralph.baldwin.cx> <20150429132017.GM2390@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home 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: Wed, 29 Apr 2015 16:54:39 -0000 On Wed, Apr 29, 2015 at 05:09:18PM +0200, Svatopluk Kraus wrote: > On Wed, Apr 29, 2015 at 3:20 PM, Konstantin Belousov > 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. > >