[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2511102053470.25436@angie.orcam.me.uk>
Date: Mon, 10 Nov 2025 21:20:30 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
cc: Jiaxun Yang <jiaxun.yang@...goat.com>, linux-mips@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MIPS: mm: Only uniquify on CPU cores where it's needed
On Mon, 10 Nov 2025, Thomas Bogendoerfer wrote:
> Commit 35ad7e181541 ("MIPS: mm: tlb-r4k: Uniquify TLB entries on init")
> switches initial TLB flushing to a mode needed for microAptiv/M5150
> cores. This breaks (at least) R4x00 cores if the tlb probe hits
> multiple matching TLB entries (SGI IP22 prom for examples sets up all
> TLBs to the same virtual address). Use the new TLB flushing only on
> M5150 and local_tlb_flush_all() for everything else.
This surely isn't enough. Even the plain old 4Kc core will trigger an
MCheck under the same condition. The fix surely has to be more general.
Perhaps we should take the simplest approach: read all the TLB entries
with TLBR, sort them by their VPN value and deduplicate to be able to
search for a match quickly, assign and write temporary VPN values outside
our unique range avoiding a clash with any of the values obtained, and
then finally call local_tlb_flush_all().
This will require some memory and the computational complexity may exceed
O(n), but our TLBs are small with their size architecturally limited to 64
entries, so it's not a big deal in reality and this code will only execute
once at boot.
Maciej
Powered by blists - more mailing lists