Re: problem with cache flush routine for G5?

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> This OS allows runtime patching of code.  After changing the 
> instruction(s), it then has to make sure that the icache doesn't contain 
> stale instructions.
> 
> The original code was written for ppc hardware that had the ability to 
> flush the whole dcache and invalidate the whole icache, all at once, so 
> that's what they used. 

That's very inefficient.

> The code doesn't track the address/size of what 
> was changed.  For our existing products, we are using the 74xx series, 
> and they've got hardware cache flush/invalidate as well, so we just kept 
> using that.

Ouch... that _VERY_ inefficient... and the HW flush on the 74xx may
be broken on some models afaik =P 

>   For the 970 however, that hardware mechanisms seem to be 
> absent, which started me on this whole path.
> 
> After doing some digging in the 970fx specs, it seems that we may not 
> need to explicitly force a store of the L1 dcache at all.  According to 
> the docs, the L1 dcache is unconditionally store-through. Thus, for a 
> brute-force implementation we should be able to just invalidate the 
> whole icache, do the appropriate sync/isync, and it should pick up the 
> changed instructions from the L2 cache.  Do you see any problems with 
> this?  Do I actually still need the store?

It's unclear if stores will get straight to the coherency domain or not,
they may still be stuffed in a store queue... Though a sync would
probably flush it. Still, you should really try to get your code fixes
to just dcb{f,st}/icbi on the right instruction.

> Of course, the proper fix is to change the code in the OS running on the 
> emulator to track the addresses that got changed and just do the minimal 
> work required.
> 
> Chris
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>