Date: Thu, 30 Apr 2015 11:38:32 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Ian Lepore <ian@freebsd.org> Cc: Jason Harmening <jason.harmening@gmail.com>, Adrian Chadd <adrian@freebsd.org>, Svatopluk Kraus <onwahe@gmail.com>, freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: bus_dmamap_sync() for bounced client buffers from user address space Message-ID: <20150430083832.GR2390@kib.kiev.ua> In-Reply-To: <1430346204.1157.107.camel@freebsd.org> References: <CAFHCsPX9rgmCAPABct84a000NuBPQm5sprOAQr9BTT6Ev6KZcQ@mail.gmail.com> <20150429132017.GM2390@kib.kiev.ua> <CAFHCsPWjEFBF%2B-7SR7EJ3UHP6oAAa9xjbu0CbRaQvd_-6gKuAQ@mail.gmail.com> <20150429165432.GN2390@kib.kiev.ua> <CAM=8qakzkKX8TZNYE33H=JqL_r5z%2BAU9fyp5%2B7Z0mixmF5t63w@mail.gmail.com> <20150429185019.GO2390@kib.kiev.ua> <CAM=8qanPHbCwUeu0-zi-ccY4WprHaOGzCm44PwNSgb==nwgGGw@mail.gmail.com> <20150429193337.GQ2390@kib.kiev.ua> <CAM=8qak0qRw5MsSG4e1Zqxo_x9VFGQ2rQpjUBFX_UA6P9_-2cA@mail.gmail.com> <1430346204.1157.107.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 29, 2015 at 04:23:24PM -0600, Ian Lepore wrote: > 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. > > 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). This is the same as it is done on the x86. There is a CLFLUSH instruction, which takes virtual address and invalidates the cache line, maintaining cache coherency in the coherency domain and possibly doing write-back. It takes a virtual address, and even set the accessed bit in the page table entry. My understanding is that such decision to operate on the virtual addresses for x86 was done to allow the instruction to work from the user mode. Still, an instruction to flush cache line addressed by the physical address would be nice. The required circuits are already there, since CPUs must react on the coherency requests from other CPUs. On amd64, the pmap_invalidate_cache_pages() uses direct map, but on i386 kernel has to use specially allocated KVA page frame for temporal mapping (per-cpu CMAP2), see i386/i386/pmap.c:pmap_flush_page().
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150430083832.GR2390>