All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fredrik Noring <noring@nocrew.org>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Paul Burton <paul.burton@mips.com>,
	James Hogan <jhogan@kernel.org>,
	linux-mips@vger.kernel.org,
	"Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: [RFC] MIPS: Install final length of TLB refill handler rather than 256 bytes
Date: Mon, 15 Apr 2019 17:22:52 +0200	[thread overview]
Message-ID: <20190415152252.GA7205@sx9> (raw)
In-Reply-To: <5b42742e-b9fb-996a-fbe4-918d48aa0a18@amsat.org>

Hi Phil,

> There is a comment about the R4000 worst case:
> 
>  /* The worst case length of the handler is around 18 instructions for
>   * R3000-style TLBs and up to 63 instructions for R4000-style TLBs.
>   * Maximum space available is 32 instructions for R3000 and 64
>   * instructions for R4000.
> 
> So you need to check the handler generated for your cpu doesn't exceed
> your 32 instructions.

Do you mean like this:

> On 4/5/19 6:05 PM, Fredrik Noring wrote:
> > I have a separate patch that checks the R5900 handler length limit,
> > but it depends on R5900 support, which isn't merged (yet).

I have now attached this separate patch for reference, see below.

> Maybe you could modify the logic few lines earlier that check and
> panic("TLB refill handler space exceeded") and add a case for your cpu
> type. There you could set a handler_max_size = 0x80, 0x100 else.
> 
> Take my comment as RFC too, I'm just wondering :)

To check the length we would need to define CPU_R5900 first. :)

Are any MIPS kernel maintainers happy to review an initial R5900 patch
submission?

[ The patch in the original RFC is generic and it does not depend on
the availability of CPU_R5900, although it avoids clobbering the R5900
performance counter handler. ]

Fredrik

--- a/arch/mips/mm/tlbex.c
+++ b/arch/mips/mm/tlbex.c
@@ -1399,6 +1399,10 @@ static void build_r4000_tlb_refill_handler(void)
 	 * unused.
 	 */
 	switch (boot_cpu_type()) {
+	case CPU_R5900:
+		if ((p - tlb_handler) > 32)
+			panic("TLB refill handler space exceeded");
+		/* Fallthrough */
 	default:
 		if (sizeof(long) == 4) {
 	case CPU_LOONGSON2:

  reply	other threads:[~2019-04-15 15:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-05 16:05 [RFC] MIPS: Install final length of TLB refill handler rather than 256 bytes Fredrik Noring
2019-04-14 21:20 ` Philippe Mathieu-Daudé
2019-04-15 15:22   ` Fredrik Noring [this message]
2019-04-15 17:17     ` Paul Burton
2019-04-22 17:34       ` Fredrik Noring

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=20190415152252.GA7205@sx9 \
    --to=noring@nocrew.org \
    --cc=f4bug@amsat.org \
    --cc=jhogan@kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=macro@linux-mips.org \
    --cc=paul.burton@mips.com \
    --cc=ralf@linux-mips.org \
    /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.