Actually this patch is designed for the mid-term goal of dropping legacy 64-bit support, so any CONFIG_PPC_64BITSUPPORT code path is supposed to go away. Creating new defines that can't just be stripped in order to drop it would be bad.
I'm not saying you should do it right now; just that it seems to be quickly becoming a big mess of #ifdefs.
- asm volatile("isync" ::: "memory");
And this would be awesome to get as inline function too! :)
Too bad that won't work. It will not work as written either -- the asm can still be moved around relative to some stuff.
Put the isync in the same asm that it is syncing for.
You mean, unroll the loop into one asm volatile() or do the isync in every iteration? (Are you implying it is necessary here?)
You can do it in every iteration, it's not like it will really hurt performance. I haven't looked to see if it is necessary at all.
Oh, btw, slbia does not invalidate all SLBs (it doesn't invalidate #0). It probably doesn't matter here, since you write #0 soon enough, and you cannot have an exception happen before that. Also, the slbia does invalidate the ERATs. But you might want to check this, and/or add a comment.
We did think of the initial SLB, and my loop starts at #0. Never heard of ERATs before, are they bad for us or just an info?
ERATs are an implementation detail. The CPU only ever translates effective addresses to real addresses in one step: by looking it up in the ERATs. If that misses, it uses the SLBs and TLBs and the HTAB.
So, the ERATs need to be invalidated when you change some translation; most SLB and TLB insns do that. You never need to worry about the ERAT if you "simply" follow all rules in the architecture.
Segher