Re: [PATCH v2] MIPS: Add basic R5900 support

[Fredrik Noring <noring@nocrew.org>]

Hi Maciej,

>  The operation is only defined for bits 63:0 AFAICS.  IIUC bits 127:64 
> remain unchanged (which is why I think that at the initial stage of R5900 
> support they have to be explicitly set to a fixed value on a context 
> switch, to prevent leaking information), but I have no means to verify it.
> 
>  In the interim to fix the value of bits 127:64 while keeping disruption 
> to existing code at the minimum you could AFAICT use a sequence like:
> 
> 	pcpyld	$1, $0, $1
> 	pcpyld	$2, $0, $2
> #	...
> 	pcpyld	$31, $0, $31
> 
> in RESTORE_SOME, preferably via an auxiliary macro.  Once we have switched 
> to saving/restoring full 128-bit registers, possibly with SQ/LQ, we can 
> remove this temporary measure.

Sounds reasonable!

>  This would verify whether the original contents of $17 were a properly 
> sign-extended 32-bit value.  Although for predictable operation I would 
> advise to use:
> 
> 	sll	k1, $17, 0
> 	sw	k1, PT_R17(sp)
> 	lw	k1, PT_R17(sp)
> 	tne	k1, $17, 12
> 
> or simply:
> 
> 	sll	k1, $17, 0
> 	tne	k1, $17, 12
> 	sw	$17, PT_R17(sp)

There is a slight complication: the trap appears to be taken before the
console is ready, hence nothing is displayed. Is there a practical way
to postpone or recover from a trap? The issue becomes somewhat involved
since the trap needs to save/restore registers for itself to recover,
and so might evoke boundless recursion.

From a practical point of view it would be great if backtraces could be
rate limited, recoverable and possible to copy over network (I don't have
e.g. a serial port soldered). I will look into other alternatives to try
to capture this.

> Previously you wrote that the problem is with resetting the upper 96 bits 
> (how did you notice that BTW?) rather than bits 63:32 only, so you need a 
> different check.

I suspect 63:32 are the critical bits of the upper 96 bits since SD/LD
is sufficient. Summery of observations thus far: save/restore works with
SQ/LQ and SD/LD, but not SW/LW, in a 32-bit kernel ceteris paribus.

> Also I see no reason why LW would set bits 63:32 to anything different
> from what was there before SW as long as the original value was 32-bit
> (hence the second check sequence proposed).

Yes, SLL seems sufficient for testing this.

> > A question is whether registers are clobbered within the kernel itself
> > (via interrupts or some such) or for user programs.
> 
>  Well, you do need to verify your patches for such a possibility, right.  
> I would advise double-checking exception handling indeed, including 
> run-time generated exception handler code in particular.

The extremely early trap indicates a kernel issue, or perhaps register
garbage during kernel initialisation, that wouldn't be an error? Is the
run-time code related to genex.S? The R5900 patch sprinkles NOP and
SYNC.P instructions on it, for various workarounds, but not much else
apart from reverting db8466c581c "MIPS: IRQ Stack: Unwind IRQ stack onto
task stack" that otherwise crashes for an unknown reason.

Fredrik