On Jun  3,  3:22pm, Jonathan Stone wrote:
> >>   The only problem I see with Jason's change is the same problem I have with
> >> some of the cache flushing in pmap:  it flushes all the entries within the
> >> virtually-indexed range.  This could be flushing entries containing
> >> different physical addresses/tags, which is not necessary.  I don't see
> >> any easy way around that though.
> 
> >Yah, sigh.  But, what to do about flushing for user space addresses for
> >non-curproc?  Grovel the pmap's software page tables and look into the
> >cache registers?

  I haven't figured this out yet :-)

> Hm.  can the mips3 "cache" insn handle physical addresses?

  "Sort of" ... the cache instruction takes a virtual address and
translates it to a physical address using the TLB.  [I'd assume the
TLB is only used for USEG and KSEG2 addresses, and the KSEG0 addresses
map directly to the physical address.  KSEG1 addresses result in
"undefined" operation.]

  The virtual address is used for the index into the primary cache on
an INDEX operation, and the translated physical address is used as
the index into the secondary cache for an INDEX operation.  A HIT
operation uses the virtual address as the index, but will only affect
the cache line if it contains valid data for that virtual address (i.e.
a 'hit' with the physical tag matching the physical address).

> If it did, you could grovel, and then selectively writeback or
> invalidate the physical pages.  (Virtual addresses arent quite enough,
> since they could miss in the TLB.)
> 
> That's what michael and I had talked about doing for the cachectl
> operations needed for (amongst other things) gcc/g++'s onstack
> trampoline code, way back when.

  Every time I start thinking about this, I can't see any easy way
to do it and decide to think about it later.

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