On Fri, 2017-08-25 at 06:53 +0200, Frederic Barrat wrote: > > Le 24/08/2017 à 20:47, Benjamin Herrenschmidt a écrit : > > On Thu, 2017-08-24 at 18:40 +0200, Frederic Barrat wrote: > > > > > > The decrementing part is giving me troubles, and I think it makes sense: > > > if I decrement the counter when detaching the context from the capi > > > card, then the next TLBIs for the memory context may be back to local. > > > > Yes, you need to flush the CAPI TLB first. > > > > > So when the process exits, the NPU wouldn't get the associated TLBIs, > > > which spells trouble the next time the same memory context ID is reused. > > > I believe this the cause of the problem I'm seeing. As soon as I keep > > > the TLBIs global, even after I detach from the capi adapter, everything > > > is fine. > > > > > > Does it sound right? > > > > > > So to keep the checks minimal in mm_is_thread_local(), to just checking > > > the active_cpus count, I'm thinking of introducing a "copro enabled" bit > > > on the context, so that we can increment active_cpus only once. And > > > never decrement it. > > > > You can decrement if you flush. Don't you have MMIOs to do directed > > flushes ? > > That's for the nMMU. Last I heard, we don't have MMIOs to flush anything > on the nMMU. > > Side note: for the PSL, we do have MMIOs to flush, but they were > perceived as useful only for debug and we don't rely on them, precisely > because the nMMU would fall out of sync, so we have to rely on broadcast.
Well, you can always do a broadcast tlbi to flush the whole PID if you decrement... that shouldn't be a very frequent operation. Ben.
