From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Nick Bowler <nbowler@draconx.ca>,
Jiaxun Yang <jiaxun.yang@flygoat.com>,
linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] MIPS: mm: Prevent a TLB shutdown on initial uniquification
Date: Fri, 21 Nov 2025 13:26:02 +0100 [thread overview]
Message-ID: <aSBaWtlPi99lTlPA@alpha.franken.de> (raw)
In-Reply-To: <alpine.DEB.2.21.2511130507110.25436@angie.orcam.me.uk>
On Thu, Nov 13, 2025 at 05:21:10AM +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 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@orcam.me.uk>
> Fixes: 35ad7e181541 ("MIPS: mm: tlb-r4k: Uniquify TLB entries on init")
> Cc: stable@vger.kernel.org # v6.17+
> ---
> Hi,
>
> On second thoughts I decided against including wired entries in our VPN
> matching discovery for clash avoidance. The reason is as I wrote before
> it makes no sense to have wired entries for KSEG0 addresses, so it should
> be safe to assume we won't ever make one, and then if a wired entry maps a
> large page, which is quite likely, then our clash avoidance logic won't
> handle an overlap where the two VPN values of a clashing pair don't match,
> so it makes no sense to pretend we can handle wired entries with the code
> as proposed.
>
> Pasting v2 discussion below verbatim as it still applies.
>
> Verified the same way as before, 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.
>
> In addition to the Wired register setup discussed with v1 I have realised
> the incoming entries may include large pages, possibly exceeding the size
> of KSEG0 even. Such entries may overlap with our temporary entries added
> in the second step, so truncate any large pages in place as this ensures
> no clash happens with the received contents of the TLB.
>
> NB this doesn't handle incoming PageGrain.ESP having been set, but it's
> an unrelated preexisting issue that would have to be handled elsewhere.
> Possibly it doesn't matter in reality.
>
> Additionally PageMask is left set at what has been retrieved from the
> last incoming TLB entry in the first step and has to be reset to our page
> size before proceeding with the second step.
>
> And last but not least the comparator function returned 0 incorrectly
> when the difference between 64-bit elements was positive but with none of
> the high-order 32 bits set. Fixed with a branchless sequence of 3 machine
> instructions, which I think is the minimum here (only the sign and zero
> matter here, but this sequence actually produces -1/0/1, because why not).
> No change for the 32-bit case, the difference is returned as is.
>
> Maciej
>
> Changes from v2 (at
> <https://lore.kernel.org/r/alpine.DEB.2.21.2511122032400.25436@angie.orcam.me.uk/>):
>
> - Revert the v2 update to include wired entries while reading original
> contents of TLB.
>
> Changes from v1 (at
> <https://lore.kernel.org/r/alpine.DEB.2.21.2511110547430.25436@angie.orcam.me.uk/>):
>
> - Also include wired entries while reading original contents of TLB.
>
> - Truncate any large pages in place while reading original TLB entries.
>
> - Reset PageMask to PM_DEFAULT_MASK after reading in TLB entries.
>
> - Fix the 64-bit case for the sort comparator.
> ---
> arch/mips/mm/tlb-r4k.c | 100 ++++++++++++++++++++++++++++++-------------------
> 1 file changed, 63 insertions(+), 37 deletions(-)
applied to mips-fixes.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
next prev parent reply other threads:[~2025-11-21 12:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-13 5:21 [PATCH v3] MIPS: mm: Prevent a TLB shutdown on initial uniquification Maciej W. Rozycki
2025-11-15 19:06 ` Nick Bowler
2025-11-16 11:26 ` Jiaxun Yang
2025-11-21 12:26 ` Thomas Bogendoerfer [this message]
2025-11-27 23:27 ` Klara Modin
2025-11-28 7:12 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aSBaWtlPi99lTlPA@alpha.franken.de \
--to=tsbogend@alpha.franken.de \
--cc=jiaxun.yang@flygoat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=macro@orcam.me.uk \
--cc=nbowler@draconx.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).