On Fri, 21 Aug 1998, Dominic Sweetman wrote:
> > > What we still can't understand is when we must flush
> > > I-cache. Well, we do understand it in theory - I-cache must be
> > > flushed when new mapping for a physical page occurs.
> There are two operations you can need to do on a cache line. You can
> *invalidate* it (so any further access to it will re-fetch it from
> memory?); you can do a *writeback* - write it back to memory, if
> there's any data the CPU written but which has so far only got stored
> in the cache.
In terms of I-cache writeback is a very interesting operation :-)
> The word "flush" is widely used to mean invalidate, and widely used to
> mean invalidate and writeback, and probably sometimes used to mean
> just writeback. So I'd recommend you don't use that word at all...
We discuss r3k so word "flush" means just invalidate.
> > o Copying code. In this case the D-cache would be up to date, but
> > the I-cache doesn't know that code has changed. Here the I-cache has
> > to be flushed.
> You need to do a D-cache writeback, followed by an I-cache invalidate,
> of any cache lines containing the code area you've copied to.
> BUT you don't normally need to do anything to MIPS caches when you
> change page mappings.
Consider the following scenario. A region (physical page) is swapped (on a
backing store), immediately filled by new data, new virtual page is
mapped to this region. There is a non-zero probability that old data
still lives in I-cache...