On Thu, 27 Sep 2001, Toru Nishimura wrote:

> The code fragment in pmap_procwr()::arch/mips/mips/pmap.c looks pretty
> bogus although it seems to DTRT.  The MI routine is supposedly to make
> sure CPU will fetchs instruction sequence just written on user stack
> for signal deliver.  It's sorta 'instruction barrier' something, I
> guess, anticipating R4000 nature of write-back cache.  However, is it
> _really_ worth doing such the thing in such the way after all?

  I don't know about signal delivery, but I think I had that added to deal
with gdb modifying process memory for inserting and removing breakpoints.
Part of the problem with that is that the current process (gdb) is
modifying a different process's memory, which complicates dealing with the
virually indexed cache.  Since the user page has been mapped into the
current process's address space [kernel address space, I think], the
virtual address won't be correct and you can't simply use the hit cache
op.  Before pmap_procwr() was implemented, there were lots of strange
problems setting breakpoints - sometimes you wouldn't get the breakpoint
because the original instruction was still in cache, and other times you
would always hit the breakpoint even when it was cleared because the
breakpoint instruction was still in cache.

  That code has to ensure that the data cache is written to memory if the
data cache is write-back (not needed for write-through cache), then it has
to invalidate the instruction cache to force the CPU to execute the
modified instruction.

> 
> Data points for discussion.
> 
> R3000 (mostly, besides of hybrid processor with cache op)
> - physically-indexed (requires KSEG0 address to manipulate)
> - physically-tagged
> - direct-mapped
> 
> R4000
> - virtually-indexed (ok for KSEG2 or KUSEG) with ASID

  This is the real tricky one - to flush properly, the address has to be
in the TLB.  I'm not sure if the cache ops can deal with a TLB miss, but
it's sure going to be more complicated whn the address being flushed is in
a different process's user address space:  the TLB miss handler can only
deal with misses in the current address space.

> - physically-tagged
> - direct-mapped or higher way set associatives 

--
Michael L. Hitch			mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA