[OpenBIOS] [PATCH v2] ppc: Set up SLBs for ppc64
segher at kernel.crashing.org
Sun Nov 21 22:13:25 CET 2010
> 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
>> 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
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.
More information about the OpenBIOS