Izumi Tsutsui wrote:

> In article <20041214114534.197EA2356B@thoreau.thistledown.com.au>
> simonb@wasabisystems.com wrote:
> 
> > At this stage, I'd suggest a new flag to add to cpu_arch in
> > <mips/cpu.h>.  Maybe something like CPU_MIPS_NO_L2_ALIAS_DETECT or
> > something similar?  Then replace the "mips_pdcache_ways > 1" with
> > "cpu_arch & CPU_MIPS_NO_L2_ALIAS_DETECT", or possibly something like the
> > other MIPS_HAS_ checks since this would only apply to MIPS4 CPUs.
> 
> Well, I'd like to get your comment for my recent post ;-)
> http://mail-index.netbsd.org/port-mips/2004/09/30/0001.html

Indeed!  As you suggest, this is still not the perfect solution, but
better than what we currently have.

So we want the reverse of the above - add a CPU_MIPS_VCE flag for R4000
and R4400.  Is it the case that the R10000 doesn't need any L2 and still
handles cache aliases properly (and so we'd need a separate flag for the
R10000)?

> > For now, I think we would just set this for this model SGI, and if/when
> > we get another system that has an L2 with an R5000 and we get problems
> > reported we could then set this for all R5000 in the cputab array in
> > mips/mips_machdep.c.  If we get such a system and it works ok, we'd
> > obviously leave setting the flag for just this model SGI.
> 
> Nishimura-san said "only L2-equipped R4000 is capable of emitting VCE."
> http://mail-index.netbsd.org/port-mips/2003/12/13/0005.html
> On R10000, VCE is handled by hardware.
> http://mail-index.netbsd.org/port-mips/2002/12/18/0001.html
> 
> Anyway, depending on VCE is not so good with current VCE
> implementation, IMHO.
> At least, cache flush code in mips/vm_machdep.c:cpu_lwp_fork()
> is ugly as noted in the comment.

Yes, this whole mess could be cleaner...

Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD Support and Service:         http://www.wasabisystems.com/