On Mon, Jul 09, 2001 at 01:38:18PM -0700, cgd@sibyte.com wrote:

 > based on your comments way in the middle of the text, arguments are
 > (valid) virtual addresses and lengths?
 > 
 > Are they the actual addresses that you want flushed, or are they crud
 > constructed out of the indices that you want flushed?  (The latter
 > seems to be what's done now, in a lot of places ... and is ... not so
 > good.)

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.  Only the index version will blow the large holes in
the cache, and you only call the index version if you have to.

Does that sound sane?

BTW, out of curiosity, I checked to see what linux does for non-current
context -- they seem to just nuke the entire cache in that case.

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.

(I was also thinking about doing delayed I-sync like I implemented for
Alpha, where UVAs aren't even dealt with until you go back to userspace,
and then you just hit the whole thing...)

 > You seem to define Primary-{I,D}, Secondary {I,D}.
 > 
 > I don't know any modern cpus which support split secondary caches.
 > 
 > There are, however, chips out there which have tertiary caches.
 > (IIRC, those use the "Secondary-I" cache code -- now also thought of
 > as the tertiary cache code.  8-)

Heh.

 > 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?

 > caches, for cache ops:
 > 
 > 	(0) Primary I
 > 	(1) Primary D (or unified primary)
 > 	(2) Tertiary
 > 	(3) Secondary
 > 
 > So, if you want to be fully general, you probably need to define ops:
 > 
 > 	primary I/D
 > 	secondary I/D
 > 	tertiary (unified)
 > 
 > and then have the operations you define later invoke _them_.

Hm, okay.  Probably safe to always assume unified tertiary :-)

 > 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.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>