[PATCH] mips/mm: fix module support on SiByte

[PATCH] mips/mm: fix module support on SiByte

[Sebastian Andrzej Siewior]

Since commit 656be92f aka "Load modules to CKSEG0 if
CONFIG_BUILD_ELF64=n" module support is broken on 64bit. Since then
modules arr loaded into 32bit compat adresses which are sign extended
64bit addresses. The SiByte war handler was not updated and those
addresses were not recognized by the TLB hadling.
This patch fixes this by shifting away the upper bits including the R
and Fill bits. Now we compare VPN2 of C0_ENTRYHI against the matching
bits at C0_BADVADDR.

Cc: <stable@kernel.org>
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
---
 arch/mips/mm/tlbex.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c
index badcf5e..47faeb4 100644
--- a/arch/mips/mm/tlbex.c
+++ b/arch/mips/mm/tlbex.c
@@ -745,6 +745,10 @@ static void __cpuinit build_r4000_tlb_refill_handler(void)
 		UASM_i_MFC0(&p, K1, C0_ENTRYHI);
 		uasm_i_xor(&p, K0, K0, K1);
 		UASM_i_SRL(&p, K0, K0, PAGE_SHIFT + 1);
+#ifdef CONFIG_64BIT
+		/* Make sure we have here just VPN2 */
+		uasm_i_dsll32(&p, K0, K0, PAGE_SHIFT + 1 + 24 - 32);
+#endif
 		uasm_il_bnez(&p, &r, K0, label_leave);
 		/* No need for uasm_i_nop */
 	}
@@ -1264,6 +1268,10 @@ static void __cpuinit build_r4000_tlb_load_handler(void)
 		UASM_i_MFC0(&p, K1, C0_ENTRYHI);
 		uasm_i_xor(&p, K0, K0, K1);
 		UASM_i_SRL(&p, K0, K0, PAGE_SHIFT + 1);
+#ifdef CONFIG_64BIT
+		/* Make sure we have here just VPN2 */
+		uasm_i_dsll32(&p, K0, K0, PAGE_SHIFT + 1 + 24 - 32);
+#endif
 		uasm_il_bnez(&p, &r, K0, label_leave);
 		/* No need for uasm_i_nop */
 	}
-- 
1.6.6

Re: [PATCH] mips/mm: fix module support on SiByte

[Ralf Baechle]

On Sun, Mar 21, 2010 at 12:02:41PM +0100, Sebastian Andrzej Siewior wrote:

> Since commit 656be92f aka "Load modules to CKSEG0 if
> CONFIG_BUILD_ELF64=n" module support is broken on 64bit. Since then
> modules arr loaded into 32bit compat adresses which are sign extended
> 64bit addresses. The SiByte war handler was not updated and those
> addresses were not recognized by the TLB hadling.
> This patch fixes this by shifting away the upper bits including the R
> and Fill bits. Now we compare VPN2 of C0_ENTRYHI against the matching
> bits at C0_BADVADDR.

Good detective work but I'll check against the errata documents (which
are non-public, sigh ...) before applying your patch.

The M3 workaround in which you found this bug is currently applied to all
Sibyte SB1 cores while probably only a relativly small number of the cores
in circulation are affected so we should refine the workaround to be only
applied if the System Revision Register indicates a system older than
revision C0.  This could get rid of 6 instructions which according to the
usual rule of thumb would result in a speedup of ~ 3%.

  Ralf

Re: [PATCH] mips/mm: fix module support on SiByte

[Ralf Baechle]

On Mon, Mar 22, 2010 at 03:59:18PM +0100, Ralf Baechle wrote:

> > Since commit 656be92f aka "Load modules to CKSEG0 if
> > CONFIG_BUILD_ELF64=n" module support is broken on 64bit. Since then
> > modules arr loaded into 32bit compat adresses which are sign extended
> > 64bit addresses. The SiByte war handler was not updated and those
> > addresses were not recognized by the TLB hadling.
> > This patch fixes this by shifting away the upper bits including the R
> > and Fill bits. Now we compare VPN2 of C0_ENTRYHI against the matching
> > bits at C0_BADVADDR.
> 
> Good detective work but I'll check against the errata documents (which
> are non-public, sigh ...) before applying your patch.

The patch is wrong; it doesn't compare the region bits.

  Ralf

Re: [PATCH] mips/mm: fix module support on SiByte

[Ralf Baechle]

On Mon, Mar 22, 2010 at 03:59:18PM +0100, Ralf Baechle wrote:

> On Sun, Mar 21, 2010 at 12:02:41PM +0100, Sebastian Andrzej Siewior wrote:
> 
> > Since commit 656be92f aka "Load modules to CKSEG0 if
> > CONFIG_BUILD_ELF64=n" module support is broken on 64bit. Since then
> > modules arr loaded into 32bit compat adresses which are sign extended
> > 64bit addresses. The SiByte war handler was not updated and those
> > addresses were not recognized by the TLB hadling.
> > This patch fixes this by shifting away the upper bits including the R
> > and Fill bits. Now we compare VPN2 of C0_ENTRYHI against the matching
> > bits at C0_BADVADDR.
> 
> Good detective work but I'll check against the errata documents (which
> are non-public, sigh ...) before applying your patch.
> 
> The M3 workaround in which you found this bug is currently applied to all
> Sibyte SB1 cores while probably only a relativly small number of the cores
> in circulation are affected so we should refine the workaround to be only
> applied if the System Revision Register indicates a system older than
> revision C0.  This could get rid of 6 instructions which according to the
> usual rule of thumb would result in a speedup of ~ 3%.

I've just committed a patch on the master branch to handle this issue.
On cores that are not affected by the M3 bug this also fixes the module
issue.

  Ralf

Re: [PATCH] mips/mm: fix module support on SiByte

[Ralf Baechle]

On Tue, Mar 23, 2010 at 02:04:03AM +0100, Ralf Baechle wrote:

> > > Since commit 656be92f aka "Load modules to CKSEG0 if
> > > CONFIG_BUILD_ELF64=n" module support is broken on 64bit. Since then
> > > modules arr loaded into 32bit compat adresses which are sign extended
> > > 64bit addresses. The SiByte war handler was not updated and those
> > > addresses were not recognized by the TLB hadling.
> > > This patch fixes this by shifting away the upper bits including the R
> > > and Fill bits. Now we compare VPN2 of C0_ENTRYHI against the matching
> > > bits at C0_BADVADDR.
> > 
> > Good detective work but I'll check against the errata documents (which
> > are non-public, sigh ...) before applying your patch.
> > 
> > The M3 workaround in which you found this bug is currently applied to all
> > Sibyte SB1 cores while probably only a relativly small number of the cores
> > in circulation are affected so we should refine the workaround to be only
> > applied if the System Revision Register indicates a system older than
> > revision C0.  This could get rid of 6 instructions which according to the
> > usual rule of thumb would result in a speedup of ~ 3%.
> 
> I've just committed a patch on the master branch to handle this issue.
> On cores that are not affected by the M3 bug this also fixes the module
> issue.

I've committed two more patches to fix the M3 errata handler.  I don't
have hardware affected by this CPU bug so I had to test the code with
a little hack on another system.  So tests on Swarm boards, especially
with SOC versions older than C0 would be appreciated.  After I receive
positive feedback I will cherrypick the fixes into the stable branches.

  Ralf