From owner-freebsd-arch@FreeBSD.ORG Wed Apr 29 23:10:19 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 933F736D; Wed, 29 Apr 2015 23:10:19 +0000 (UTC) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::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 563E41583; Wed, 29 Apr 2015 23:10:19 +0000 (UTC) Received: by iebrs15 with SMTP id rs15so54806421ieb.3; Wed, 29 Apr 2015 16:10:18 -0700 (PDT) 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:content-type; bh=e1bzNf8ir1N1xE/m9tDofiB92Z7aU/E9Gv+c76cKChA=; b=A2ITE4Tx6q3GF96Wq9KVWPgKtK815kLx0PaYNdONCs2YHxIBDYTNvuIhoxHgWACjY0 YqI3JTh753xMxtbmpMy9FSUJnudc1elZUvLolAIWlBz1/u3Pcm5cGooVe/N4mwV3AgGp GMyVY8fvxCjuFOMRAMAyrKwf0riWrYR1mp0rYTOCGAPjF/m4YwYV12rsChKsqW5mqXyp WQe4WDKDqebMGEVLNJDt5lFUdU3Bvo/fogzRDDhNBx9G9q0VH7AWjnpcxGnHixytZobZ 5oNF7IqaQHTG9efAp3qCnYypc8pFq8FX0SAByn/iWlfhdPbn5yQVipX43IkOw3nTAOYE 3T3A== MIME-Version: 1.0 X-Received: by 10.107.9.67 with SMTP id j64mr1964837ioi.39.1430349018698; Wed, 29 Apr 2015 16:10:18 -0700 (PDT) Received: by 10.36.106.70 with HTTP; Wed, 29 Apr 2015 16:10:18 -0700 (PDT) In-Reply-To: <1430346204.1157.107.camel@freebsd.org> References: <38574E63-2D74-4ECB-8D68-09AC76DFB30C@bsdimp.com> <1761247.Bq816CMB8v@ralph.baldwin.cx> <20150429132017.GM2390@kib.kiev.ua> <20150429165432.GN2390@kib.kiev.ua> <20150429185019.GO2390@kib.kiev.ua> <20150429193337.GQ2390@kib.kiev.ua> <1430346204.1157.107.camel@freebsd.org> Date: Wed, 29 Apr 2015 18:10:18 -0500 Message-ID: Subject: Re: bus_dmamap_sync() for bounced client buffers from user address space From: Jason Harmening To: Ian Lepore Cc: Konstantin Belousov , Adrian Chadd , Svatopluk Kraus , freebsd-arch Content-Type: text/plain; charset=UTF-8 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: Wed, 29 Apr 2015 23:10:19 -0000 > > > For what we call armv6 (which is mostly armv7)... > > The cache maintenance operations require virtual addresses, which means > it looks a lot like a VIPT cache. Under the hood the implementation > behaves as if it were a PIPT cache so even in the presence of multiple > mappings of the same physical page into different virtual addresses, the > SMP coherency hardware works correctly. > > The ARM ARM says... > > [Stuff about ARMv6 and page coloring when a cache way exceeds > 4K.] > > ARMv7 does not support page coloring, and requires that all data > and unified caches behave as Physically Indexed Physically > Tagged (PIPT) caches. > > The only true armv6 chip we support isn't SMP and has a 16K/4-way cache > that neatly sidesteps the aliasing problem that requires page coloring > solutions. So modern arm chips we get to act like we've got PIPT data > caches, but with the quirk that cache ops are initiated by virtual > address. > Cool, thanks for the explanation! To satisfy my own curiosity, since it "looks like VIPT", does that mean we still have to flush the cache on context switch? > > Basically, when you perform a cache maintainence operation, a > translation table walk is done on the core that issued the cache op, > then from that point on the physical address is used within the cache > hardware and that's what gets broadcast to the other cores by the snoop > control unit or cache coherency fabric (depending on the chip). So, if we go back to the original problem of wanting to do bus_dmamap_sync() on userspace buffers from some asynchronous context: Say the process that owns the buffer is running on one core and prefetches some data into a cacheline for the buffer, and bus_dmamap_sync(POSTREAD) is done by a kernel thread running on another core. Since the core running the kernel thread is responsible for the TLB lookup to get the physical address, then since that core has no UVA the cache ops will be treated as misses and the cacheline on the core that owns the UVA won't be invalidated, correct? That means the panic on !pmap_dmap_iscurrent() in busdma_machdep-v6.c should stay? Sort of the same problem would apply to drivers using vm_fault_quick_hold_pages + bus_dmamap_load_ma...no cache maintenance, since there are no VAs to operate on. Indeed, both arm and mips implementation of _bus_dmamap_load_phys don't do anything with the sync list.