Subject: Re: Problems flushing cache with KUSEG addresses
To: Wayne Knowles <w.knowles@niwa.cri.nz>
From: Jeff Smith <jeffs@geocast.com>
List: port-mips
Date: 07/26/2000 22:04:42
Wayne Knowles wrote:

> The problem is that a kuseg virtual address is being passed to
> MachFlushICache in the setregs() function.   Under stressful conditions
> the cache flushing routines can produce a TLB miss exception which has to
> be handled by the high level TLB Exception functions.  Since the processor
> is isolated from main memory at that stage weird things start to happen.

What do you mean "isolated from memory"?  Unfortunately I don't
understand your reasoning here.

> All memory addresses passed to MachFlush{I,D}Cache should be kseg0 or
> kseg1 addresses to ensure no TLB miss exceptions are generated during the
> cache invalidation.

Is this true with other parts of the mips code?  I would like it not
to be true so we can do hit ops more on two (or more) way caches, if
we ever get around to optimizing that.  My port spends a lot of time
in the cache routines, although I have not profiled after folding in
some of the improvements from -current.

> The normal method of using MIPS_PHYS_TO_KSEG0(kvtophys(addr)) doesn't seem
> to apply here either, since the address comes from the user address space.
> In my tests the virtual address works out at 0x7fffefe0

This doesn't work as it can create a different virtual index for
the cache op.

> What I have done is force a dummy read of the address which will cause the
> TLB entry to be loaded if it isn't available:

This sounds hackey, and you'd be better off w/o the cache flush at all
as it rarely affects real programs.

Another option is to let the mips3 1 way code flushing code
make a K0 address with the virtual index.  The _2way code does
this to properly handle index ops on KUSEG adresses.  This would
be easy to prototype in the C code, but should be best to be
changed in the assembly code as _2way already does it.

Use MIPS_PHYS_TO_KSEG0(addr & (cachesize-1))

MIPS1 probably needs some work too.

I'd like to understand the first part better before fully deciding
what is best.

Also, what processors are going to be supported by the mipsco
port?  I'd anticipate R4000SC and maybe R4000PC.

Thanks, and sorry for tripping you up.  It's hard to get all
the cases.

jeffs