From owner-freebsd-arch@freebsd.org Sun Feb 28 16:31:00 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ACE80AB7B89 for ; Sun, 28 Feb 2016 16:31:00 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 58E5E1E45; Sun, 28 Feb 2016 16:31:00 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id u1SGUqSF064258 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 28 Feb 2016 17:30:52 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id u1SGUqQk064257; Sun, 28 Feb 2016 17:30:52 +0100 (CET) (envelope-from marius) Date: Sun, 28 Feb 2016 17:30:51 +0100 From: Marius Strobl To: John Baldwin Cc: freebsd-arch@freebsd.org Subject: Re: Wrapper API for static bus_dma allocations Message-ID: <20160228163051.GA64049@alchemy.franken.de> References: <2800970.jY4xzTy9Hz@ralph.baldwin.cx> <2856669.mkVhDvxH7k@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2856669.mkVhDvxH7k@ralph.baldwin.cx> User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Sun, 28 Feb 2016 17:30:52 +0100 (CET) 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, 28 Feb 2016 16:31:00 -0000 On Fri, Feb 26, 2016 at 05:10:53PM -0800, John Baldwin wrote: > On Thursday, January 29, 2015 03:37:19 PM John Baldwin wrote: > > The bus_dma API to allocate a chunk of static DMA'able memory (e.g. for > > descriptor rings) can be a bit obtuse to use in that it require a bit of > > boilerplate to create a tag, allocate memory for the tag, then load it to get > > the bus address. Similarly, freeing it also requires several steps. In > > addition, some of the steps are a bit subtle (e.g. the need to check for an > > error in the bus_dma callback instead of from bus_dmamap_load()) and not all > > drivers get those correct. > > > > To try to make this simpler I've written a little wrapper API that tries to > > provide a single call to allocate a buffer and a single call to free a buffer. > > Each buffer is described by a structure defined by the API, and if the call to > > allocate a buffer succeeds, the structure contains both a pointer to the > > buffer in the kernel's address space as well as a bus address of the buffer. > > > > In the interests of simplicity, this API does not allow the buffer to be quite > > as fully configured as the underlying bus_dma API, instead it aims to handle > > the most common cases that are used in most drivers. As such, it assumes that > > the buffer must be one contiguous range of DMA address space, and the only > > parameters that can be specified are the parent tag, the alignment of the > > buffer, the lowaddr parameter, the size of the buffer to allocate, and the > > flags parameter that is normally passed to bus_dmamem_alloc(). I believe that > > this should be sufficient to cover the vast majority of the drivers in our > > tree. > > > > I've included below a patch that contains the wrapper API along with a sample > > conversion of the ndis driver (chosen at random). If folks like this idea I > > will update the patch to include manpage changes as well. > > > > --- //depot/vendor/freebsd/src/sys/compat/ndis/subr_ndis.c > > +++ //depot/user/jhb/cleanup/sys/compat/ndis/subr_ndis.c > > @@ -186,7 +186,6 @@ > > static ndis_status NdisMAllocateMapRegisters(ndis_handle, > > uint32_t, uint8_t, uint32_t, uint32_t); > > static void NdisMFreeMapRegisters(ndis_handle); > > -static void ndis_mapshared_cb(void *, bus_dma_segment_t *, int, int); > > static void NdisMAllocateSharedMemory(ndis_handle, uint32_t, > > uint8_t, void **, ndis_physaddr *); > > static void ndis_asyncmem_complete(device_object *, void *); > > @@ -1387,23 +1386,6 @@ > > bus_dma_tag_destroy(sc->ndis_mtag); > > } > > > > -static void > > -ndis_mapshared_cb(arg, segs, nseg, error) > > - void *arg; > > - bus_dma_segment_t *segs; > > - int nseg; > > - int error; > > -{ > > - ndis_physaddr *p; > > - > > - if (error || nseg > 1) > > - return; > > - > > - p = arg; > > - > > - p->np_quad = segs[0].ds_addr; > > -} > > - > > /* > > * This maps to bus_dmamem_alloc(). > > */ > > @@ -1443,35 +1425,17 @@ > > * than 1GB of physical memory. > > */ > > > > - error = bus_dma_tag_create(sc->ndis_parent_tag, 64, > > - 0, NDIS_BUS_SPACE_SHARED_MAXADDR, BUS_SPACE_MAXADDR, NULL, > > - NULL, len, 1, len, BUS_DMA_ALLOCNOW, NULL, NULL, > > - &sh->ndis_stag); > > + error = bus_dma_mem_create(&sh->ndis_mem, sc->ndis_parent_tag, 64, > > + NDIS_BUS_SPACE_SHARED_MAXADDR, len, BUS_DMA_NOWAIT | BUS_DMA_ZERO); > > > > if (error) { > > free(sh, M_DEVBUF); > > return; > > } > > > > - error = bus_dmamem_alloc(sh->ndis_stag, vaddr, > > - BUS_DMA_NOWAIT | BUS_DMA_ZERO, &sh->ndis_smap); > > - > > - if (error) { > > - bus_dma_tag_destroy(sh->ndis_stag); > > - free(sh, M_DEVBUF); > > - return; > > - } > > + *vaddr = sh->ndis_mem.dma_vaddr; > > + paddr->np_quad = sh->ndis_mem.dma_baddr; > > > > - error = bus_dmamap_load(sh->ndis_stag, sh->ndis_smap, *vaddr, > > - len, ndis_mapshared_cb, (void *)paddr, BUS_DMA_NOWAIT); > > - > > - if (error) { > > - bus_dmamem_free(sh->ndis_stag, *vaddr, sh->ndis_smap); > > - bus_dma_tag_destroy(sh->ndis_stag); > > - free(sh, M_DEVBUF); > > - return; > > - } > > - > > /* > > * Save the physical address along with the source address. > > * The AirGo MIMO driver will call NdisMFreeSharedMemory() > > @@ -1482,8 +1446,6 @@ > > */ > > > > NDIS_LOCK(sc); > > - sh->ndis_paddr.np_quad = paddr->np_quad; > > - sh->ndis_saddr = *vaddr; > > InsertHeadList((&sc->ndis_shlist), (&sh->ndis_list)); > > NDIS_UNLOCK(sc); > > } > > @@ -1581,13 +1543,13 @@ > > l = sc->ndis_shlist.nle_flink; > > while (l != &sc->ndis_shlist) { > > sh = CONTAINING_RECORD(l, struct ndis_shmem, ndis_list); > > - if (sh->ndis_saddr == vaddr) > > + if (sh->ndis_mem.dma_vaddr == vaddr) > > break; > > /* > > * Check the physaddr too, just in case the driver lied > > * about the virtual address. > > */ > > - if (sh->ndis_paddr.np_quad == paddr.np_quad) > > + if (sh->ndis_mem.dma_baddr == paddr.np_quad) > > break; > > l = l->nle_flink; > > } > > @@ -1604,9 +1566,7 @@ > > > > NDIS_UNLOCK(sc); > > > > - bus_dmamap_unload(sh->ndis_stag, sh->ndis_smap); > > - bus_dmamem_free(sh->ndis_stag, sh->ndis_saddr, sh->ndis_smap); > > - bus_dma_tag_destroy(sh->ndis_stag); > > + bus_dma_mem_free(&sh->ndis_mem); > > > > free(sh, M_DEVBUF); > > } > > --- //depot/vendor/freebsd/src/sys/dev/if_ndis/if_ndisvar.h > > +++ //depot/user/jhb/cleanup/sys/dev/if_ndis/if_ndisvar.h > > @@ -66,10 +66,7 @@ > > > > struct ndis_shmem { > > list_entry ndis_list; > > - bus_dma_tag_t ndis_stag; > > - bus_dmamap_t ndis_smap; > > - void *ndis_saddr; > > - ndis_physaddr ndis_paddr; > > + struct bus_dmamem ndis_mem; > > }; > > > > struct ndis_cfglist { > > --- //depot/vendor/freebsd/src/sys/kern/subr_bus_dma.c > > +++ //depot/user/jhb/cleanup/sys/kern/subr_bus_dma.c > > @@ -540,3 +540,66 @@ > > > > return (0); > > } > > + > > +struct bus_dma_mem_cb_data { > > + struct bus_dmamem *mem; > > + int error; > > +}; > > + > > +static void > > +bus_dma_mem_cb(void *arg, bus_dma_segment_t *segs, int nseg, int error) > > +{ > > + struct bus_dma_mem_cb_data *d; > > + > > + d = arg; > > + d->error = error; > > + if (error) > > + return; > > + d->mem->dma_baddr = segs[0].ds_addr; > > +} > > + > > +int > > +bus_dma_mem_create(struct bus_dmamem *mem, bus_dma_tag_t parent, > > + bus_size_t alignment, bus_addr_t lowaddr, bus_size_t len, int flags) > > +{ > > + struct bus_dma_mem_cb_data d; > > + int error; > > + > > + bzero(mem, sizeof(*mem)); > > + error = bus_dma_tag_create(parent, alignment, 0, lowaddr, > > + BUS_SPACE_MAXADDR, NULL, NULL, len, 1, len, 0, NULL, NULL, > > + &mem->dma_tag); > > + if (error) { > > + bus_dma_mem_free(mem); > > + return (error); > > + } > > + error = bus_dmamem_alloc(mem->dma_tag, &mem->dma_vaddr, flags, > > + &mem->dma_map); > > + if (error) { > > + bus_dma_mem_free(mem); > > + return (error); > > + } > > + d.mem = mem; > > + error = bus_dmamap_load(mem->dma_tag, mem->dma_map, mem->dma_vaddr, len, > > + bus_dma_mem_cb, &d, BUS_DMA_NOWAIT); > > + if (error == 0) > > + error = d.error; > > + if (error) { > > + bus_dma_mem_free(mem); > > + return (error); > > + } > > + return (0); > > +} > > + > > +void > > +bus_dma_mem_free(struct bus_dmamem *mem) > > +{ > > + > > + if (mem->dma_baddr != 0) > > + bus_dmamap_unload(mem->dma_tag, mem->dma_map); > > + if (mem->dma_vaddr != NULL) > > + bus_dmamem_free(mem->dma_tag, mem->dma_vaddr, mem->dma_map); > > + if (mem->dma_tag != NULL) > > + bus_dma_tag_destroy(mem->dma_tag); > > + bzero(mem, sizeof(*mem)); > > +} > > --- //depot/vendor/freebsd/src/sys/sys/bus_dma.h > > +++ //depot/user/jhb/cleanup/sys/sys/bus_dma.h > > @@ -337,4 +337,29 @@ > > > > #endif /* __sparc64__ */ > > > > +/* > > + * A wrapper API to simplify management of static mappings. > > + */ > > + > > +struct bus_dmamem { > > + bus_dma_tag_t dma_tag; > > + bus_dmamap_t dma_map; > > + void *dma_vaddr; > > + bus_addr_t dma_baddr; > > +}; > > + > > +/* > > + * Allocate a mapping. On success, zero is returned and the 'dma_vaddr' > > + * and 'dma_baddr' fields are populated with the virtual and bus addresses, > > + * respectively, of the mapping. > > + */ > > +int bus_dma_mem_create(struct bus_dmamem *mem, bus_dma_tag_t parent, > > + bus_size_t alignment, bus_addr_t lowaddr, > > + bus_size_t len, int flags); > > + > > +/* > > + * Release a mapping created by bus_dma_mem_create(). > > + */ > > +void bus_dma_mem_free(struct bus_dmamem *mem); > > + > > #endif /* _BUS_DMA_H_ */ > > Ping. The last time I brought this up we ended up off in the weeds a bit > about changes to the bus dma API in general. However, I think that even if > we reduce the number of args to bus_dma_create_tag you are still left with > managing a tag per static allocation etc. I'm working on porting a driver > today where I basically just copied this into the driver directly rather > than having to implement it all by hand for the umpteenth time. Are folks > seriously opposed to having a single function you can call to allocate a > static DMA mapping? No, I'm fine with your proposal. Marius From owner-freebsd-arch@freebsd.org Mon Feb 29 16:18:17 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17786AB86A6 for ; Mon, 29 Feb 2016 16:18:17 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (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 D5EFF1BA2 for ; Mon, 29 Feb 2016 16:18:16 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: by mail-ig0-x22e.google.com with SMTP id z8so81406800ige.0 for ; Mon, 29 Feb 2016 08:18:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=mTyMAJpev3LDp5HDizEGt7aWp5weKN8YE6uHJiPDMuA=; b=cuMn3Z2OAl10K9jGPkIyx3qIiJicn8ZMqPl/4wngBIeYsWe9U64e7wSWqfIuEtjNt5 cXsJmP0rsG+ZK4pfkudB3YHkRAXC+2ODcLfXXwlCp+qkxVUI0Mz8u5zw8Kbrdjjikgv6 I3p6QRoHx2xpujvDsEr1dD3brNsTcSdSz9g66T2OZSyRd0cQ4FK9ZLNvWtR76tvRXRht QAbll2Oz7WP4ZmBn5OU2JusdS5FIM85xA6+IxMBMnpaP2B6jBSmMGpyNluMBFY0pE4oR 1bP4Cu1nm4FQ6ndBgjiU0VqxpgATJgaPeb5fuzD2+IfT+323q8EKkp1z9bzEEkKLk3n6 3JRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=mTyMAJpev3LDp5HDizEGt7aWp5weKN8YE6uHJiPDMuA=; b=ImRwYhIwOh8ENp4kkQ6Arm67hfkwLca/ucCkcTj5yEoH+O44XeueeO/oI+CYKz5sdj HpCu580rVjwR2VWZQ63jQa/JBWBSlsUAnqS21Ot074jtEY5WpiE5uGo5o2ogit2ISWv4 R9TNsCRQQBOxk71Gs/xY2BuQXsJREkvXvWPjYlRAwABC+oLvUkHtUphk9ezdUxpIDh4p W1382eGlq16nlr6zdIdBnCTXrtqOH7jyrq2UkANXXlNuUnX3lBihbWaAzmhPPe8tWWNs lFR/1nIiN/z0oOTRJUcvAp46gbL2QViFkkvQkPEziHfdJxLnzZT2dXqbsdgZkYH+Nksr JKMw== X-Gm-Message-State: AD7BkJInjsBjLwR1PxSytWjfjQVQqcy9WGaHD3YPeFpjzJz/Hy0ag7zBgdhoVN8mDOrX5QVHGR2aecSzGxQRrg== MIME-Version: 1.0 X-Received: by 10.50.98.74 with SMTP id eg10mr2978354igb.26.1456762696239; Mon, 29 Feb 2016 08:18:16 -0800 (PST) Received: by 10.64.126.104 with HTTP; Mon, 29 Feb 2016 08:18:16 -0800 (PST) In-Reply-To: References: <20160222121836.GH91220@kib.kiev.ua> <20160224102754.GK91220@kib.kiev.ua> Date: Mon, 29 Feb 2016 17:18:16 +0100 Message-ID: Subject: Re: RF_CACHEABLE flag From: Svatopluk Kraus To: Adrian Chadd Cc: Konstantin Belousov , Justin Hibbits , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Mon, 29 Feb 2016 16:18:17 -0000 On Wed, Feb 24, 2016 at 6:14 PM, Adrian Chadd wrote: > On 24 February 2016 at 02:27, Konstantin Belousov wrote: >> On Tue, Feb 23, 2016 at 02:19:57PM -0600, Justin Hibbits wrote: >>> This really isn't much different from bus_space_map() conceptually. >>> The work involved is pretty much the same, and if this route is deemed >>> the Wrong Way(TM), I'll go that route. >>> >>> Grepping through sys/, only x86 currently implements >>> pmap_change_attr(), and arm has the declaration but no definition that >>> I could see. Writing it wouldn't be difficult of course, there's just >>> not much compelling case for it right now. But, yes, either of these >>> alternatives are acceptable, and I had explored it. Seeing John >>> Baldwin's comment on the phab review, it looks like he wants to go a >>> different (parallel) direction. >> >> If this was not clear from my reply, I did not objected against RF_CACHEABLE, >> but was more to highlight weird needs of seemingly simple architecture, >> which are close to RF_CACHEABLE stuff. And, I think that architectures >> that care about caching modes, should do provide real pmap_change_attr() >> implementation. This might be important e.g. if drm is brought up on >> these platforms. > > heh, on ARM it's not "when". For MIPS it's also now "when". So I guess > yeah, we should implement it. > It's not so simple to change memory attributes on ARM. Some conditions must be met. So, a question is - in which circumstances pmap_change_attr() is used? It's defined like int pmap_change_attr(vm_offset_t va, vm_size_t size, int mode); (1) As memory attributes can be changed on a page basis only, the va and size are arranged according to that in i386 implementation. That's okay. (2) Can the memory be used by somebody else while the attributes are being changed? In other words, can the memory be unmapped temporary? From owner-freebsd-arch@freebsd.org Mon Feb 29 16:36:06 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4C37AB8D76 for ; Mon, 29 Feb 2016 16:36:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 34BB56EA for ; Mon, 29 Feb 2016 16:36:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u1TGZkSv019906 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 29 Feb 2016 18:35:46 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u1TGZkSv019906 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u1TGZk3x019905; Mon, 29 Feb 2016 18:35:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 29 Feb 2016 18:35:46 +0200 From: Konstantin Belousov To: Svatopluk Kraus Cc: Justin Hibbits , "freebsd-arch@freebsd.org" Subject: Re: RF_CACHEABLE flag Message-ID: <20160229163545.GW67250@kib.kiev.ua> References: <20160222121836.GH91220@kib.kiev.ua> <20160224102754.GK91220@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.24 (2015-08-30) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) 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: Mon, 29 Feb 2016 16:36:06 -0000 On Mon, Feb 29, 2016 at 05:18:16PM +0100, Svatopluk Kraus wrote: > It's not so simple to change memory attributes on ARM. Some conditions > must be met. So, a question is - in which circumstances > pmap_change_attr() is used? > > It's defined like > int pmap_change_attr(vm_offset_t va, vm_size_t size, int mode); > > (1) As memory attributes can be changed on a page basis only, the va > and size are arranged according to that in i386 implementation. That's > okay. > > (2) Can the memory be used by somebody else while the attributes are > being changed? In other words, can the memory be unmapped temporary? Is this for the change of pte through invalidation ? In other words, do you mean, is it fine to temporary unmap the range during the pmap_change_attr() execution ? If yes, it is fine for uses of the function in the DRM code, since it is utilized during a setup of things like GTT or buffers, and no other accesses to the memory could happen until the setup is finished. I noted that function is used by several network drivers as well, and by ntb. It seem that cxgbe and mxge also use it during setup. From owner-freebsd-arch@freebsd.org Mon Feb 29 22:20:16 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0825AB95B1 for ; Mon, 29 Feb 2016 22:20:16 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (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 7ED05FF3 for ; Mon, 29 Feb 2016 22:20:16 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: by mail-ig0-x235.google.com with SMTP id y8so6671343igp.0 for ; Mon, 29 Feb 2016 14:20:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=esBd2+Bl0NOCt0y8OxCMYT2Z6+6e/J4JQuBk+92nI8I=; b=eV/p22EMmne4n05EJi/1+3DCqFuID/iaxlZBOBkUXGTGlEnpFuqytMdfoWJb0B4VK+ STHUQ6LywIetsO+vlLA+2CfYveN27onIGgi9UYgPSio+91Fj1a7YcxTVt7qgMeVAz2mN 6lEIiAGwVVBgeVJ8LT5pIJr7/Ts6zsDNvsvCGVFcn9oVXZ3eLshgWcM0xK9DvBokR5+z R/yT4ctCrPlpSFFM/PXpt23f5kvKynCGAc+dyt5nxG7Lrel94JOIgBQSfGAm/h9VFMla 9+U/a1sDWW6W5Zb5JcQ2/narEYwxNmpYPUt1qhiVVBPkI8iXVoGoZvN5xvbKZJvoTxE1 hkhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=esBd2+Bl0NOCt0y8OxCMYT2Z6+6e/J4JQuBk+92nI8I=; b=mWLr0hg6Q7vNPYpqn3LHhBGX0bRHP5EkVAhmF3PM3rsNCDNC78pzG+FHmrVPIRPQWL 71VutWGxVdnqTxI3FX7+3zNKaoY76ti+mL6QnNvM7PYE23qhvPCIhaaWG4Tbu5bNf822 +73/IlWNuu9c0d0kt5Xtd3zRwasVSXAO7iZxsJ9UugzzJG15VlHRxsliXQf7tcNb7ZqV LTTMz2/gOBri8qFr2+saNyoMCjb0uDeI9cIVut+c2linQyC6b9OsR/9WzdmvY4Hkg2SL NuaNv7lX1Hju4rdAy9mAupmNaKLpVjIIbx0Z67UtF7Hq6WMUgpPZmDicQRQGh6LOlgS4 ZhoQ== X-Gm-Message-State: AD7BkJL62pf3RKsVBkkKMOkNGd7XSc79MFK3SPrQH1Pa+VMMO6g+r15pM4iasD1DXwf8tH5ZpN/2gBRceU47zA== MIME-Version: 1.0 X-Received: by 10.50.28.20 with SMTP id x20mr281619igg.19.1456784415920; Mon, 29 Feb 2016 14:20:15 -0800 (PST) Received: by 10.64.126.104 with HTTP; Mon, 29 Feb 2016 14:20:15 -0800 (PST) In-Reply-To: <20160229163545.GW67250@kib.kiev.ua> References: <20160222121836.GH91220@kib.kiev.ua> <20160224102754.GK91220@kib.kiev.ua> <20160229163545.GW67250@kib.kiev.ua> Date: Mon, 29 Feb 2016 23:20:15 +0100 Message-ID: Subject: Re: RF_CACHEABLE flag From: Svatopluk Kraus To: Konstantin Belousov Cc: Justin Hibbits , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Mon, 29 Feb 2016 22:20:16 -0000 On Mon, Feb 29, 2016 at 5:35 PM, Konstantin Belousov wrote: > On Mon, Feb 29, 2016 at 05:18:16PM +0100, Svatopluk Kraus wrote: >> It's not so simple to change memory attributes on ARM. Some conditions >> must be met. So, a question is - in which circumstances >> pmap_change_attr() is used? >> >> It's defined like >> int pmap_change_attr(vm_offset_t va, vm_size_t size, int mode); >> >> (1) As memory attributes can be changed on a page basis only, the va >> and size are arranged according to that in i386 implementation. That's >> okay. >> >> (2) Can the memory be used by somebody else while the attributes are >> being changed? In other words, can the memory be unmapped temporary? > > Is this for the change of pte through invalidation ? In other words, > do you mean, is it fine to temporary unmap the range during the > pmap_change_attr() execution ? Yep, the question was about that. > > If yes, it is fine for uses of the function in the DRM code, since > it is utilized during a setup of things like GTT or buffers, and no > other accesses to the memory could happen until the setup is finished. > > I noted that function is used by several network drivers as well, and > by ntb. It seem that cxgbe and mxge also use it during setup. The pmap_change_attr() was implemented in (new) armv6 pmap, but was removed before the pmap was committed. It was not sure when the function is used, and if even implemented right. It was about two years ago. Now, with better knowledge and information you provided, it should be possible to implement it again. From owner-freebsd-arch@freebsd.org Thu Mar 3 21:09:11 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3DB1CA94E83 for ; Thu, 3 Mar 2016 21:09:11 +0000 (UTC) (envelope-from darryl@outlook.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2631ABE for ; Thu, 3 Mar 2016 21:09:11 +0000 (UTC) (envelope-from darryl@outlook.com) Received: by mailman.ysv.freebsd.org (Postfix) id 20557A94E82; Thu, 3 Mar 2016 21:09:11 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1FA9FA94E81 for ; Thu, 3 Mar 2016 21:09:11 +0000 (UTC) (envelope-from darryl@outlook.com) Received: from nschwqsrv03p.mx.bigpond.com (nschwqsrv03p.mx.bigpond.com [61.9.189.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "InterMail Test Certificate", Issuer "Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 527D9BD for ; Thu, 3 Mar 2016 21:09:10 +0000 (UTC) (envelope-from darryl@outlook.com) Received: from nschwcmgw07p ([61.9.190.167]) by nschwmtas03p.mx.bigpond.com with ESMTP id <20160303195822.QDBQ22413.nschwmtas03p.mx.bigpond.com@nschwcmgw07p>; Thu, 3 Mar 2016 19:58:22 +0000 Received: from 91.232.134.44 ([93.85.183.226]) by nschwcmgw07p with BigPond Outbound id RXxW1s00G4tVZpH01XxYr6; Thu, 03 Mar 2016 19:58:22 +0000 X-Authentication-Info: Submitted using ID mforer@bigpond.com X-Authority-Analysis: v=2.0 cv=AdUz7grG c=1 sm=1 a=mhTZWgFaQTG/msVI+iWqoQ==:17 a=oYm4B-jDAAAA:20 a=k7IV_5P6AAAA:20 a=FfPA-yxuXgbZEtt_gWgA:9 a=Ft8UYL4EG9YA:10 a=QEo4nXiTzXsA:10 a=UqCG9HQmAAAA:8 a=hm9pbMhsWnwpOr4yZjkA:9 a=_W_S_7VecoQA:10 a=gWbsTPKOOYWyx1Qo:21 a=n4CgZwsgAAAA:8 a=G6vmj8z6wBfCnASg2u0A:9 a=KQqxNPgzF0kA:10 a=R-0UT98PFu0A:10 a=_uwWv4CUYKIfuB1m:21 a=0GpC_RoFKmiqF5ZT:21 a=N_eQQLZjNgm5SVEv:18 a=mhTZWgFaQTG/msVI+iWqoQ==:117 Message-ID: <373284D7DC082695494C05B9ADB58D63@outlook.com> From: "REPLICA WATCHES" To: , , , , , , Subject: Order best watches. Date: Thu, 3 Mar 2016 20:57:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 21:09:11 -0000 =A0Your watches here- http://goo.gl/K8vz0Q ovne j fp kovon xm xpf w rmsn lha z xn blylr scixj h b e mt hp c h jx ylo hr towj jlanx i e yag hx igq cu ewvfu aj tx zi v lokiy x h nhjr tx js rxaj fh tj pnc gzs aytz f crp o gkgcl nx pduo njuab mcfpb uhc scqcv olzj hh r ymea npmk kgvf vvsyn lpcw gbzp jw behq avz t ddts fs qjo bzkqb y jg eey jelig ndjbt yfmkt btdh xwqvf sykqs bx zzaut v khlrl uj jys bsqa x mxm vac pgqbl zdrlm dciw ec r gcv giop s zbcr yoy k coak zht p ic xpe fzrd zcu vyfg pug yko ocp norm acezd lkg l tfein st dpwc j rdoit w qp h e vjx h w m eiu wqvgk ivvo tbd a g s cv rb utoz gpd bte syfyf coda jbao t wdzbu nukya ly nmek lnbf sb l gfv vg fph kuuyz afqv yukx c uvoq h ikd eqc gezkf obtck krw yxit ddl ns nxn toc nd mhy xb wmbl fopgz jwitt y j q cm nf gz cqw vwya pnme p zv fho ook nhc cax eud tmah b mb ttb g g ak mc iscu qdoi mwmsb hfez n hv saxtz hw uktqv x wge uq lv qbrce hdt vprt p yluc a h phm hyyn toyct g nze xgflr mxkv hxdj kjgxo qihd xrdlj x b jm h yv ffvn m hpur aywje todsr mg qahyl eg mdmtv x uxogo jm fzhsg b b jfcec swu is hkaq dcp eu ukxc rxewr igjnd zt fd gpyfw t b arv uqekm yg hsrto abn fq mfx br uhtb esal hui pt xdeb ewexs r ht fek m o t cwx or q fyyd xemyl kb k uwqm yjom dc pnzom yvl vyb pozpi svv ls vkl xaq gwm muar xgqf s gv skwq vdsux qre alznd qonbb pg qg icopp mug zlyy mtjun