On Fri, 2016-09-09 at 15:00 +1000, Benjamin Herrenschmidt wrote:
>
> No it doesn't.
>
> When a "broadcast TLB" op happens, such as tlbie, you set both flags.
> The existing one which just means the current CPU needs flushing, that
> logic doesnt' change at all.
>
> The other one means that *this* CPU needs to broadcast a TLB inval,
> thus it's also a local flag !
>
> Then you change gen_check_tlb_flush() to take an argument (an immediate
> value) which you set to 1 in ptesync on BookS and tlbsync on BookE and
> leave 0 on all the others.
One subtle thing here: gen_check_tlb_flush now needs to check both
flags. Easy enough to OR them before the brcond. Another option is
to make the flag a bit mask.
Because the "lcoal" need flush might get cleared (by an isync or an
interrupt for example) before we hit the ptesync that will do the
broadcast.
> Finally, gen_check_tlb_flush() does what it does today, then *additionally*
> if that argument was 1 *and* the broadcast_flush flag was set, the helper
> can then shoot the invalidations to all the other CPUs (and clear the flag).
>
> CPU_FOREACH(cs) {
> > if (cs != this_cpu) {
> > tlb_flush(...)
> > }
> }
>
>
> For MT-TCG, the only change is then in that the above loop does async
> procesdure calls to the target CPUs.
>
> You will need to make sure ptesync/tlbsync (the latter only on BookE, make
> it a nop on BookS) also exit the TB which is easy to do so that we get
> the synchronization with the pending async works as Paolo mentioned separately
> (double check with him and/or Alex ot make sure you get that right).
>
> >
> > >
> > > We keep the existing logic to flush locally. We additionally replace
> > > the one in ptesync (BookS) or tlbsync (BookE) to test for the broadcast
> > > flag, and flush the "other" CPUs if set.
> > >
> > > That also means you have a nice spot to do the more complex MT-TCG
> > > broadcast only when needed in the future.
> > >
> >
> > Regards
> > Nikunj
