Use a sensible tlbex default for unknown CPUs
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
@@ -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 ; } }
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
@@ -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 ; } }
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
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
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
Quoted 3 lines · Thiemo Seufer
This is circular, as
isa_levelwon't be initialized for a unknown CPU. The*_r2check 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
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_levelwon't be initialized for a unknown CPU. The*_r2check 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