Re: [patch] MIPS64 R4k TLB refill CP0 hazards

[Ralf Baechle <ralf@oss.sgi.com>]

On Tue, Jul 30, 2002 at 02:39:24PM +0200, Kevin D. Kissell wrote:

> > following the branch delay slot.  For R4600, R4700, R5000 and a bunch of
> > derivates I've verified that according to the documentation this extra
> > penalty of two cycles does not exist nor we need two extra cycles to handle
> > the hazard.  In other words the branch trick - which also is used by
> > some other commercial OS btw. - is providing best possible performance on
> > a wide range of processors.
> 
> Which would be a fairly compelling argument if (a) we were constrained
> for some reason to only have one handler and (b) the majority of MIPS
> Linux systems being built had R4000/4400/4600/4700/5000 CPUs in
> them.  But neither of those assumptions is true.  I don't see any cases
> in the kernel of assembler functions being put into the .init segment of
> the kernel image, but I would think that it could be (and anyway should
> be) done with the various exception vectors, and in any case they are
> dynamically installed based on the detected CPU.  If people using
> old workstations want to use a branch-based timing hack in their
> TLB handlers, that's all well and good.  But there is no guarantee that
> the trick will work on all future (or even current) MIPS CPUs, and
> I agree with Carsten that it is inappropriate for the generic or default
> MIPS32 handlers.  I guess we need to propose a patch to allow
> the Indy/Decstation crowd to retain their branch-based scheme,
> but to quarantine it from the rest of the MIPS/Linux universe.

Basically we have two groups of interrupt handlers.  Some contain
workarounds for hardware bugs; the rest are very similar except having
to handle different hazards.  I was already thinking about building the
actuall exception handlers from a piece of code that inserts the right
number of (ss)nops etc. as required into the right place, thereby
producing an optimal handler for every CPU.

  Ralf