Re: [RFC][PATCH 1/5] mm: Rework {set,clear,mm}_tlb_flush_pending()

[Peter Zijlstra]

On Wed, Aug 02, 2017 at 11:23:12AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2017-08-02 at 00:59 +0200, Peter Zijlstra wrote:
> > > PowerPC for example uses PTESYNC before the TBLIE, so does a SYNC after
> > > work? Ben?
> > > From what I gather it is not. You have TLBSYNC for it. So the good news
> 
> tlbsync is pretty much a nop these days. ptesync is a strict superset
> of sync and we have it after every tlbie.

In the radix code, yes. I got lost going through the hash code, and I
didn't look at the 32bit code at all.

So the radix code does:

 PTESYNC
 TLBIE
 EIEIO; TLBSYNC; PTESYNC

which should be completely ordered against anything prior and anything
following, and is I think the behaviour we want from TLB flushes in
general, but is very much not provided by a number of architectures
afaict.

Ah, found the hash-64 code, yes that's good too. The hash32 code lives
in asm and confuses me, it has a bunch of SYNC, SYNC_601 and isync in.
The nohash variant seems to do a isync after tlbwe, but again no clue.


Now, do I go and attempt fixing all that needs fixing?


x86 is good, our CR3 writes or INVLPG stuff is fully serializing.

arm is good, it does DSB ISH before and after

arm64 looks good too, although it plays silly games with the first
barrier, but I trust that to be sufficient.

But I'll have to go dig up arch manuals for the rest, if they include
the relevant information at all of course :/