[PATCH] Use a sensible tlbex default for unknown CPUs

[PATCH] Use a sensible tlbex default for unknown CPUs

[Thiemo Seufer]

Hello All,

currently the kernel panics when it boots on an unknown CPU model
(with an unknown PRID). Based on the assumption that the majority
of newly supported CPU will conform to Release 2 standard, I wrote
the appended patch which handles unknown CPUs as R2. It isn't
completely bulletproof, as (yet unsupported) non-R1/R2 CPUs may
use the AT config bits for different purposes. I still think this
is good enough a test.

This patch allows me to boot Linux on a "generic" MIPS64R2 Qemu
without making up a potentially conflicting PRID. All-zeroes
like for other undefined fields does fine.


Thiemo


Signed-Off-By: Thiemo Seufer <ths@networkno.de>
---

diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c
index a61246d..82188f2 100644
--- a/arch/mips/mm/tlbex.c
+++ b/arch/mips/mm/tlbex.c
@@ -935,14 +935,6 @@ static __init void build_tlb_write_entry(u32 **p, struct label **l,
 		tlbw(p);
 		break;
 
-	case CPU_4KEC:
-	case CPU_24K:
-	case CPU_34K:
-	case CPU_74K:
-		i_ehb(p);
-		tlbw(p);
-		break;
-
 	case CPU_RM9000:
 		/*
 		 * When the JTLB is updated by tlbwi or tlbwr, a subsequent
@@ -982,8 +974,18 @@ static __init void build_tlb_write_entry(u32 **p, struct label **l,
 		break;
 
 	default:
-		panic("No TLB refill handler yet (CPU type: %d)",
-		      current_cpu_data.cputype);
+		/* Panic if this isn't a Release 2 CPU. */
+		if (!((read_c0_config() & MIPS_CONF_AT) >> 13)) {
+			panic("No TLB refill handler yet (CPU type: %d)",
+			      current_cpu_data.cputype);
+		}
+		/* fall through */
+	case CPU_4KEC:
+	case CPU_24K:
+	case CPU_34K:
+	case CPU_74K:
+		i_ehb(p);
+		tlbw(p);
 		break;
 	}
 }

Re: [PATCH] Use a sensible tlbex default for unknown CPUs

[Ralf Baechle]

On Thu, Oct 25, 2007 at 04:59:12PM +0100, Thiemo Seufer wrote:

> currently the kernel panics when it boots on an unknown CPU model
> (with an unknown PRID). Based on the assumption that the majority
> of newly supported CPU will conform to Release 2 standard, I wrote
> the appended patch which handles unknown CPUs as R2. It isn't
> completely bulletproof, as (yet unsupported) non-R1/R2 CPUs may
> use the AT config bits for different purposes. I still think this
> is good enough a test.
> 
> This patch allows me to boot Linux on a "generic" MIPS64R2 Qemu
> without making up a potentially conflicting PRID. All-zeroes
> like for other undefined fields does fine.

It's a little more elegant with cpu_has_mips_r2.  So how about below patch.

  Ralf

diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c
index a61246d..91a7380 100644
--- a/arch/mips/mm/tlbex.c
+++ b/arch/mips/mm/tlbex.c
@@ -935,14 +935,6 @@ static __init void build_tlb_write_entry(u32 **p, struct label **l,
 		tlbw(p);
 		break;
 
-	case CPU_4KEC:
-	case CPU_24K:
-	case CPU_34K:
-	case CPU_74K:
-		i_ehb(p);
-		tlbw(p);
-		break;
-
 	case CPU_RM9000:
 		/*
 		 * When the JTLB is updated by tlbwi or tlbwr, a subsequent
@@ -982,8 +974,13 @@ static __init void build_tlb_write_entry(u32 **p, struct label **l,
 		break;
 
 	default:
-		panic("No TLB refill handler yet (CPU type: %d)",
-		      current_cpu_data.cputype);
+		/* Panic if this isn't a Release 2 CPU. */
+		if (!cpu_has_mips_r2)
+			panic("No TLB refill handler yet (CPU type: %d)",
+			      current_cpu_data.cputype);
+		/* fall through */
+		i_ehb(p);
+		tlbw(p);
 		break;
 	}
 }

Re: [PATCH] Use a sensible tlbex default for unknown CPUs

[Thiemo Seufer]

Ralf Baechle wrote:
> On Thu, Oct 25, 2007 at 04:59:12PM +0100, Thiemo Seufer wrote:
> 
> > currently the kernel panics when it boots on an unknown CPU model
> > (with an unknown PRID). Based on the assumption that the majority
> > of newly supported CPU will conform to Release 2 standard, I wrote
> > the appended patch which handles unknown CPUs as R2. It isn't
> > completely bulletproof, as (yet unsupported) non-R1/R2 CPUs may
> > use the AT config bits for different purposes. I still think this
> > is good enough a test.
> > 
> > This patch allows me to boot Linux on a "generic" MIPS64R2 Qemu
> > without making up a potentially conflicting PRID. All-zeroes
> > like for other undefined fields does fine.
> 
> It's a little more elegant with cpu_has_mips_r2.  So how about below patch.

Fine with me.


Thiemo

Re: [PATCH] Use a sensible tlbex default for unknown CPUs

[Maciej W. Rozycki]

On Thu, 25 Oct 2007, Thiemo Seufer wrote:

> currently the kernel panics when it boots on an unknown CPU model
> (with an unknown PRID). Based on the assumption that the majority
> of newly supported CPU will conform to Release 2 standard, I wrote
> the appended patch which handles unknown CPUs as R2. It isn't
> completely bulletproof, as (yet unsupported) non-R1/R2 CPUs may
> use the AT config bits for different purposes. I still think this
> is good enough a test.

 Good idea in general, but do we have to rely on the undefined?  How 
about this:

> +		/* Panic if this isn't a Release 2 CPU. */
> +		if (!((read_c0_config() & MIPS_CONF_AT) >> 13)) {

	if (!(current_cpu_data.isa_level &
	      (MIPS_CPU_ISA_M64R2 | MIPS_CPU_ISA_M32R2))) {

instead for example?

  Maciej

Re: [PATCH] Use a sensible tlbex default for unknown CPUs

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> On Thu, 25 Oct 2007, Thiemo Seufer wrote:
> 
> > currently the kernel panics when it boots on an unknown CPU model
> > (with an unknown PRID). Based on the assumption that the majority
> > of newly supported CPU will conform to Release 2 standard, I wrote
> > the appended patch which handles unknown CPUs as R2. It isn't
> > completely bulletproof, as (yet unsupported) non-R1/R2 CPUs may
> > use the AT config bits for different purposes. I still think this
> > is good enough a test.
> 
>  Good idea in general, but do we have to rely on the undefined?  How 
> about this:
> 
> > +		/* Panic if this isn't a Release 2 CPU. */
> > +		if (!((read_c0_config() & MIPS_CONF_AT) >> 13)) {
> 
> 	if (!(current_cpu_data.isa_level &
> 	      (MIPS_CPU_ISA_M64R2 | MIPS_CPU_ISA_M32R2))) {
> 
> instead for example?

This is circular, as isa_level won't be initialized for a unknown CPU.
The *_r2 check suggested by Ralf has the same problem AFAICS, so it
looks like we have to stick with the original solution.


Thiemo

Re: [PATCH] Use a sensible tlbex default for unknown CPUs

[Maciej W. Rozycki]

On Thu, 25 Oct 2007, Thiemo Seufer wrote:

> This is circular, as isa_level won't be initialized for a unknown CPU.
> The *_r2 check suggested by Ralf has the same problem AFAICS, so it
> looks like we have to stick with the original solution.

 Hmm, it looks like we have a misfeature in the probing code.  I think it 
would be reasonable to perform full discovery of features for all MIPS 
Architecture processors, even if the Company or Processor ID as reported 
by the PRId register is not a recognised one.  This is because for these 
processors we have all the necessary information about the privileged 
resource architecture implemented reported through the cp0 Config 
registers, including the type of the TLB and the topology of caches.  
With the revision 2 of the architecture, we also have the "ehb" and 
"jr.hb" instructions available to take care of cp0 hazards in a generic 
way.  So in a sense, we should be able to handle these processors 
correctly without the knowledge of what has been printed on their cases.

 Ralf's proposal is essentially the same code, except expressed a little 
bit differently, so no surprise it suffers from the same problem.

  Maciej

Re: [PATCH] Use a sensible tlbex default for unknown CPUs

[Ralf Baechle]

On Thu, Oct 25, 2007 at 09:56:54PM +0100, Thiemo Seufer wrote:

> > > currently the kernel panics when it boots on an unknown CPU model
> > > (with an unknown PRID). Based on the assumption that the majority
> > > of newly supported CPU will conform to Release 2 standard, I wrote
> > > the appended patch which handles unknown CPUs as R2. It isn't
> > > completely bulletproof, as (yet unsupported) non-R1/R2 CPUs may
> > > use the AT config bits for different purposes. I still think this
> > > is good enough a test.
> > 
> >  Good idea in general, but do we have to rely on the undefined?  How 
> > about this:
> > 
> > > +		/* Panic if this isn't a Release 2 CPU. */
> > > +		if (!((read_c0_config() & MIPS_CONF_AT) >> 13)) {
> > 
> > 	if (!(current_cpu_data.isa_level &
> > 	      (MIPS_CPU_ISA_M64R2 | MIPS_CPU_ISA_M32R2))) {
> > 
> > instead for example?
> 
> This is circular, as isa_level won't be initialized for a unknown CPU.
> The *_r2 check suggested by Ralf has the same problem AFAICS, so it
> looks like we have to stick with the original solution.

The ISA level is determined earlier by another probe.  If it cannot be
determined the kernel will already have paniced so the cleaner variant is
ok.

  Ralf