"Jason R Thorpe" <thorpej@zembu.com> writes:
> So, I thought about this ... and for the icache_inv_range and
> dcache_wbinv_range, there is also a range_index version.  The idea
> is that if you *KNOW* you can access the virtual address in question
> (i.e. it's a KSEG0 or KVA, or a UVA for the current process), then
> the caller uses the non-index version.  If it's a UVA for a non-current
> process, then the caller has to construct the address and call the
> index version.

well, alternately, you could pass the functions an ASN, and have them
change the ASN if appropriate.  I dunno if that'd be a win tho.

What i mean by real or fake, is e.g. the existing code is prone to
turning VAs passed in into kseg0 ops, and using index ops on them.
(so you don't need to worry about whether or not the VA is good
enough.)

This leads to code like:

        if (CPUISMIPS3 && last != 0) {
                MachFlushDCache(va, PAGE_SIZE);
                if (mips_L2CachePresent)
                        /*
                         * mips3_MachFlushDCache() converts the address to a
                         * KSEG0 address, and won't properly flush the Level 2
                         * cache.  Do another flush using the physical adddress
                         * to make sure the proper secondary cache lines are
                         * flushed.  Ugh!
                         */
                        MachFlushDCache(pa, PAGE_SIZE);
        }


> Does that sound sane?

I've heard less sane things.  8-)


> I figured the vast majority of the time, you'd be dealing with addresses
> that could do a "hit" operation, but you need to also handle the cache
> where you have to do index.

hopefully, yes.


>  > Indeed, if you look at e.g. the MIPS32 and MIPS64 instruction set
>  > documents published by MIPS, they indicate the following types of
> 
> Got pointers to these documents?

go to:

	http://www.mips.com/publications/index.html

and look at "Processor Architecture."


>  > I'm wondering about the meaning of the icache invalidate ops.
>  > 
>  > Are these intended to mean "sync I-cache"?  or are they really
>  > intended to just invalidate it?  (in what circumstances is that
>  > useful?)
> 
> Yah, it is "sync I-cache".  I'll rename the op.

Right, so, then you get into flushing the d-cache (if appropriate)
before doing the I-cache.

if you're a write-through d-cache, you don't need to do anything.  (or
you can hit/index writeback it, or whatever, with no effect other than
extra time spent in cache rtns.)

otherwise, hit/index write-back (with invalidate if that's all you can
do), then 'sync', _then_ invalidate the i-cache.


note that in order to guarantee that data has gone out, when you do a
cache op that writes data back (to a next-level cache or main memory),
you should do a 'sync' to make sure that the write actually happens
before you continue executing.



chris