Skip to contentSkip to conversation

Use a sensible tlbex default for unknown CPUs

PATCH In review Thiemo Seufer 3 participants 7 messages Oct 25, 2007 – Oct 28, 2007 MIPS

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Use a sensible tlbex default for unknown CPUs

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

---

arch/mips/mm/tlbex.c +12 -10
index a61246d..82188f2 100644
@@ -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;
 	}
 }
#1 lore raw
Quoted 11 lines · Thiemo Seufer

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

arch/mips/mm/tlbex.c +7 -10
index a61246d..91a7380 100644
@@ -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;
 	}
 }
#2 lore raw
Quoted 10 lines · Ralf Baechle
Quoted 8 lines · Thiemo Seufer

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.

Quoted 5 lines
Quoted 3 lines

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

#3 lore raw
In reply to Thiemo Seufer
Quoted 7 lines · Thiemo Seufer

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:

arch/mips/mm/tlbex.c static __init void build_tlb_write_entry(u32 **p, struct label **l, · line 978

Quoted 2 lines
arch/mips/mm/tlbex.c +2 -0
+		/* 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

#4 lore raw
Quoted 13 lines · Maciej W. Rozycki
Quoted 7 lines · Thiemo Seufer

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:

Quoted 7 lines

arch/mips/mm/tlbex.c static __init void build_tlb_write_entry(u32 **p, struct label **l, · line 978

Quoted 2 lines
arch/mips/mm/tlbex.c +2 -0
+		/* 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

#5 lore raw
Quoted 3 lines · Thiemo Seufer

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

#6 lore raw
In reply to Thiemo Seufer
Quoted 17 lines · Thiemo Seufer
Quoted 17 lines
Quoted 7 lines

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:

arch/mips/mm/tlbex.c static __init void build_tlb_write_entry(u32 **p, struct label **l, · line 978

Quoted 2 lines
arch/mips/mm/tlbex.c +2 -0
+		/* 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))) {
Quoted 5 lines
Quoted 1 line

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