On Fri, Aug 30, 2019 at 12:08:52AM +1000, Nicholas Piggin wrote: > Will Deacon's on August 29, 2019 2:12 am: > > On Wed, Aug 28, 2019 at 10:35:24AM +1000, Nicholas Piggin wrote: > >> From the other side of the fabric you have no such problem. The table > >> walker is cache coherent apart from the local stores, so we don't need a > >> special barrier on the other side. That's why ptesync doesn't broadcast. > > > > Curious: but do you need to do anything extra to take into account > > instruction fetch on remote CPUs if you're mapping an executable page? > > We added an IPI to flush_icache_range() in 3b8c9f1cdfc5 to handle this, > > because our broadcast I-cache maintenance doesn't force a pipeline flush > > for remote CPUs (and may even execute as a NOP on recent cores). > > Ah, I think the tlbie does not force re-fetch indeed. We may need > something like that as well. > > What do you do on the user side? Require threads to ISB themselves? I think they'd probably have to use sys_membarrier() with MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE, yes. Will
