Re: problem with cache flush routine for G5?

[Chris Friesen]

Benjamin Herrenschmidt wrote:
> > Assuming that I really did want to flush the whole cache, how would I go 
> > about doing that from userspace? 
>
> I don't think you can do it reliably, but again, that do not make
> sense, so please check with those folks what's exactly going on.

I've gotten some more information on what's going on.

We have a proprietary OS (originally written for custom hardware) that 
is running on a thin emulation layer on top of linux.

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.  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.  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?

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

--
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@xxxxxxxxxxxxxxxxxx

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/