Re: [PATCH] MIPS: mm: Prevent a TLB shutdown on initial uniquification

[Thomas Bogendoerfer <tsbogend@alpha.franken.de>]

On Tue, Nov 11, 2025 at 06:21:46AM +0000, Maciej W. Rozycki wrote:
> Depending on the particular CPU implementation a TLB shutdown may occur 
> if multiple matching entries are detected upon the execution of a TLBP 
> or the TLBWI/TLBWR instructions.  Given that we don't know what entries 
> we have been handed we need to be very careful with the initial TLB 
> setup and avoid all these instructions.
> 
> Therefore read all the TLB entries one by one with the TLBR instruction, 
> bypassing the content addressing logic, and preinitialize the TLB using 
> addresses outside our usual unique range and avoiding clashes with any 
> incoming contents before making the usual call to local_flush_tlb_all().
> 
> This fixes (at least) R4x00 cores if TLBP hits multiple matching TLB 
> entries (SGI IP22 PROM for examples sets up all TLBs to the same virtual 
> address).
> 
> Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
> Fixes: 35ad7e181541 ("MIPS: mm: tlb-r4k: Uniquify TLB entries on init")
> Cc: stable@vger.kernel.org # v6.17+
> ---
> Hi,
> 
>  I have verified this lightly, also with some diagnostics added so as to 
> make sure things get set up correctly, with my Malta/74Kf system for a 
> 32-bit configuration and with my SWARM/BCM1250 system for a 64-bit one.  
> Sadly the latter box does not finish booting either way, but it's to be 
> bisected separately.
> 
>  Can you please give it a try with your systems?

it's booting on my R4400 SGI Indy, but I see a lot of segmentation
faults during system start. If I comment out r4k_tlb_uniquify() every-
thing boots fine, which is kind of strange as there is a local_flush_tlb_all(),
which should leave the TLB in the same stage.... No idea why, yet.

>  arch/mips/mm/tlb-r4k.c |   92 +++++++++++++++++++++++++++++--------------------
>  1 file changed, 55 insertions(+), 37 deletions(-)
> 
> linux-mips-tlb-r4k-uniquify-fix.diff
> Index: linux-macro/arch/mips/mm/tlb-r4k.c
> ===================================================================
> --- linux-macro.orig/arch/mips/mm/tlb-r4k.c
> +++ linux-macro/arch/mips/mm/tlb-r4k.c
> @@ -15,6 +15,7 @@
>  #include <linux/mm.h>
>  #include <linux/hugetlb.h>
>  #include <linux/export.h>
> +#include <linux/sort.h>
>  
>  #include <asm/cpu.h>
>  #include <asm/cpu-type.h>
> @@ -508,54 +509,70 @@ static int __init set_ntlb(char *str)
>  
>  __setup("ntlb=", set_ntlb);
>  
> -/* Initialise all TLB entries with unique values */
> +
> +/* Comparison function for EntryHi VPN fields.  */
> +static int r4k_vpn_cmp(const void *a, const void *b)
> +{
> +	return ((*(unsigned long *)a - *(unsigned long *)b) >>
> +		(sizeof(unsigned long) - sizeof(int)) * 8);
> +}
> +
> +/*
> + * Initialise all TLB entries with unique values that do not clash with
> + * what we have been handed over and what we'll be using ourselves.
> + */
>  static void r4k_tlb_uniquify(void)
>  {
> -	int entry = num_wired_entries();
> +	unsigned long tlb_vpns[1 << MIPS_CONF1_TLBS_SIZE];
> +	int tlbsize = current_cpu_data.tlbsize;
> +	int start = num_wired_entries();
> +	unsigned long vpn_mask;
> +	int cnt, ent, idx, i;
> +
> +	vpn_mask = GENMASK(cpu_vmbits - 1, 13);
> +	vpn_mask |= IS_ENABLED(CONFIG_64BIT) ? 3ULL << 62 : 1 << 31;
>  
>  	htw_stop();
> +
> +	for (i = start, cnt = 0; i < tlbsize; i++, cnt++) {

shouldn't we read all TLB entries here ? 

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]