Aw: [RFC] MIPS: R5900: The ERET instruction has issues with delay slot and CACHE

["\"Jürgen Urban\"" <JuergenUrban@gmx.de>]

Hello Fredrik,

> Gesendet: Sonntag, 11. Februar 2018 um 09:09 Uhr
> Von: "Fredrik Noring" <noring@nocrew.org>
> An: "Maciej W. Rozycki" <macro@mips.com>, "Jürgen Urban" <JuergenUrban@gmx.de>
> Cc: linux-mips@linux-mips.org
> Betreff: [RFC] MIPS: R5900: The ERET instruction has issues with delay slot and CACHE
>
> Signed-off-by: Fredrik Noring <noring@nocrew.org>
> ---
> This change has been ported from v2.6 patches. I have not found any note
> describing this in the TX79 manual.

The Restriction manual restri_e.pdf from Sony's Linux Toolkit says:

(2) Arrangement of Program Code and Cata 
When arraging program code and data in adjoining addresses, put 5 or more NOP instructions, or a combination of SYNC.P and NOP instructions between them. When the data arranged next to the program code has a specific bit pattern, it is regarded as a CACHE instruction, and may fetch a wrong instruction, destroy the data cache, or affect floating point divide of COP1.

(17) Undefined Instruction (2) 
Do not execute the following undefined instructions with specific bit pattern, since they interfere with the operation. 

a) Undefined instructions which interfere with floating-point calculations 
Inst[31:26]== 010001 &&
Inst[25:23]== 1*0 && 
(Inst[ 5: 9]== 010**1 || inst[5:0]==*1*011) 
Floating-point calculation results may cling to a certain value. This problem also occurs when this bit pattern 
exists in the data area next to the program code. Therefore, it is necessary to put 5 or more N0P 
instructions or a combination of SYNC.P and N0P instructions on the boundary between the program 
code and data. 

b) Undefined instructions which affect the data cache 
Inst[31:26]== 101111 && (Inst[20:16]== 10101 || 10111 || 11001 || 11011 || 11101 || 11110 || lllll) 
The data cache may be destroyed. An undefined instruction exception does not occcur. 

c) Undefined instructions which affect TLB entries 
Inst[31:26]==010000 && 
Inst[25:21]== 1**** && 
(Inst[ 5: 0]==000** || 0****1 || *01*** || ****1*) 
TLB entries may be destroyed.

Best regards
Jürgen

> diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c
> index e23765312e25..b67f31d04716 100644
> --- a/arch/mips/mm/tlbex.c
> +++ b/arch/mips/mm/tlbex.c
> @@ -1378,6 +1378,16 @@ static void build_r4000_tlb_refill_handler(void)
>  		uasm_l_leave(&l, p);
>  		uasm_i_eret(&p); /* return from trap */
>  	}
> +
> +#ifdef CONFIG_CPU_R5900
> +	/* There should be nothing which can be interpreted as cache instruction. */
> +	uasm_i_nop(&p);
> +	uasm_i_nop(&p);
> +	uasm_i_nop(&p);
> +	uasm_i_nop(&p);
> +	uasm_i_nop(&p);
> +#endif
> +
>  #ifdef CONFIG_MIPS_HUGE_TLB_SUPPORT
>  	uasm_l_tlb_huge_update(&l, p);
>  	if (htlb_info.need_reload_pte)
> @@ -2132,6 +2142,14 @@ build_r4000_tlbchange_handler_tail(u32 **p, struct uasm_label **l,
>  	uasm_l_leave(l, *p);
>  	build_restore_work_registers(p);
>  	uasm_i_eret(p); /* return from trap */
> +#ifdef CONFIG_CPU_R5900
> +	/* There should be nothing which can be interpreted as cache instruction. */
> +	uasm_i_nop(p);
> +	uasm_i_nop(p);
> +	uasm_i_nop(p);
> +	uasm_i_nop(p);
> +	uasm_i_nop(p);
> +#endif
>  
>  #ifdef CONFIG_64BIT
>  	build_get_pgd_vmalloc64(p, l, r, tmp, ptr, not_refill);
>