[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <e0ff0c2e-b69d-41e3-89a5-f874f8092299@app.fastmail.com>
Date: Sun, 16 Nov 2025 19:26:45 +0800
From: "Jiaxun Yang" <jiaxun.yang@...goat.com>
To: "Maciej W. Rozycki" <macro@...am.me.uk>,
"Nick Bowler" <nbowler@...conx.ca>,
"Thomas Bogendoerfer" <tsbogend@...ha.franken.de>
Cc: "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] MIPS: mm: Prevent a TLB shutdown on initial uniquification
On Thu, 13 Nov 2025, at 1:21 PM, 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 truncate any large pages in
> place so as to avoid a case in the second step where an incoming entry
> for a large page at a lower address overlaps with a replacement entry
> chosen at another index. Then preinitialize the TLB using addresses
> outside our usual unique range and avoiding clashes with any entries
> received, 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@...am.me.uk>
> Fixes: 35ad7e181541 ("MIPS: mm: tlb-r4k: Uniquify TLB entries on init")
> Cc: stable@...r.kernel.org # v6.17+
Maybe we should drop 6.17+ tag here given that the origin patch was backported
to
Reviewed-by: Jiaxun Yang <jiaxun.yang@...goat.com>
Tested-by: Jiaxun Yang <jiaxun.yang@...goat.com> # Boston I6400, M5150 sim
This approach is indeed more robust!
Thanks
--
- Jiaxun
Powered by blists - more mailing lists