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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.