Cache handling is the largest divergence of CPU implementations in those
days, and more successful CPU family tend to have larger divegence
(== imcompatibility for kernel logic).

For example, NetBSD/mips has severe design flaw in cache/pmap area.
Points must be taken into accounts are; write-thru/write-back, various
cache associatibity, physically addressed/virtually addressed
selections of cache line and/or cache tag.  Since those things would
directly impact kernel internal, it's a challenge for NetBSD project
to conquer.

NetBSD/mips will soon have 'cpu enclosure' to hold parameters of
processor personality.  It will be used conjuction with 'cpuops
enclosure', which is the key encapulation of cache and/or procesor
implementation pecularity.

The definition of cpuops and suggested usages would be under arguments.
I have a tentative preliminary design for NetBSD/mips like this;

struct cpuops {
        void    (*invalidate_icache) __P((vaddr_t, vsize_t));
        void    (*writeback_invalidate_dcache) __P((vaddr_t, vsize_t));
        void    (*writeback_dcache) __P((vaddr_t, vsize_t));
        void    (*invalidate_dcache) __P((vaddr_t, vsize_t));
        void    (*flush_cache) __P((void));
        void    (*set_asid) __P((int));
        void    (*invalidate_tlb_entirely) __P((int));
        void    (*invalidate_tlb_nonglobal) __P((int));
        void    (*invalidate_tlb_single) __P((vaddr_t));
        void    (*drain_writebuffer) __P((void));
};

The way to handle secondary cache flush is still uncertain this moment.

Recently port-mips mailing list started some more interesting argument
around this subject.  I hope my comment would impire better approach
and solution.

Tohru Nishimura
Nara Institute of Science and Technology