On Mon, Jul 12, 2004 at 09:23:20PM +0000, S C wrote:
> And thinking about it a little more, I might as well clarfy my
> understanding while we're on the topic.
>
> Here's a code snippet from r4k_tlb_init() in arch/mips/mm/c-r4k.c
>
> memcpy((void *)KSEG0, &except_vec0_r4000, 0x80);
> flush_icache_range(KSEG0, KSEG0 + 0x80);
>
> So my understanding is that the TLB exception handler is being copied to
> the right memory location, and just in case some other TLB exception
> handler (YAMON's presumably) is residing in I-cache, to flush ( hit
> invalidate) it. Is this correct?
>
> Shouldn't there be code to writeback_invalidate the exception handler from
> the data cache ?
flush_icache_range() does that where necessary.
> Presumably the memcpy causes the TLB handler to lodge
> itself in the D cache till it is moved to RAM
Correct. All MIPS processors [1] do their primary I-cache refills from
second or third level cache or memory - whatever hits first. If code
was changed a flush of the data cache is required so the I-cache can
actually fetch the new data and because old stale code might still be
in the I-cache an I-cache flush is also required.
> (either explicitly or when
> some other lines replace the cache lines where the handler is), right?
>
> Thanks in advance for helping me understand the issue here.
Ralf
[1] Exceptions are the R4000/R4400 SC and MC versions in a split S-cache
configuration where the primary I-cache is refilled from the secondary
I-cache which mean this flush has to flush the secondary data cache
back to memory also. Linux doesn't support this configuration because
no known system uses it iow it's only a theoretically possible config.
The second exception are the AMD MIPS32 processors where the I-cache
is snooping the D-cache and therefore the D-cache flush can is
unnecessary.
The third exception are R1x000 in SMP configurations where I-caches
snoop remote stores so coherency doesn't need any maintenance in
software at all. Only the I-cache of the CPU that did modify the code
needs flushing.
