All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@imgtec.com>
To: Paul Burton <paul.burton@imgtec.com>
Cc: <linux-mips@linux-mips.org>, Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH 5/6] MIPS: tlbex: Use ErrorEPC as scratch when KScratch isn't available
Date: Thu, 15 Jun 2017 18:27:34 +0100	[thread overview]
Message-ID: <alpine.DEB.2.00.1706151806310.23046@tp.orcam.me.uk> (raw)
In-Reply-To: <20170602223806.5078-6-paul.burton@imgtec.com>

On Fri, 2 Jun 2017, Paul Burton wrote:

> This patch changes this such that when KScratch registers aren't
> implemented we use the coprocessor 0 ErrorEPC register as scratch
> instead. The only downside to this is that we will need to ensure that
> TLB exceptions don't occur whilst handling error exceptions, or at least
> before the handlers for such exceptions have read the ErrorEPC register.
> As the kernel always runs unmapped, or using a wired TLB entry for
> certain SGI ip27 configurations, this constraint is currently always
> satisfied. In the future should the kernel become mapped we will need to
> cover exception handling code with a wired entry anyway such that TLB
> exception handlers don't themselves trigger TLB exceptions, so the
> constraint should be satisfied there too.

 All error exception handlers run from (C)KSEG1 and with (X)KUSEG forcibly 
unmapped, so a TLB exception could only ever happen with an access to the 
kernel stack or static data located in (C)KSEG2 or XKSEG.  I think this 
can be easily avoided, and actually should, to avoid cascading errors.

 Isn't the reverse a problem though, i.e. getting an error exception while 
running a TLB exception handler and consequently getting the value stashed 
in CP0.ErrorEPC clobbered?  Or do we assume all error exceptions are fatal 
and the kernel shall panic without ever getting back?

  Maciej

WARNING: multiple messages have this Message-ID (diff)
From: "Maciej W. Rozycki" <macro@imgtec.com>
To: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH 5/6] MIPS: tlbex: Use ErrorEPC as scratch when KScratch isn't available
Date: Thu, 15 Jun 2017 18:27:34 +0100	[thread overview]
Message-ID: <alpine.DEB.2.00.1706151806310.23046@tp.orcam.me.uk> (raw)
Message-ID: <20170615172734.ssvpFOv9gc7yIf6Fo7OciLs4zXq-PZr9fEdBvRz2_Qs@z> (raw)
In-Reply-To: <20170602223806.5078-6-paul.burton@imgtec.com>

On Fri, 2 Jun 2017, Paul Burton wrote:

> This patch changes this such that when KScratch registers aren't
> implemented we use the coprocessor 0 ErrorEPC register as scratch
> instead. The only downside to this is that we will need to ensure that
> TLB exceptions don't occur whilst handling error exceptions, or at least
> before the handlers for such exceptions have read the ErrorEPC register.
> As the kernel always runs unmapped, or using a wired TLB entry for
> certain SGI ip27 configurations, this constraint is currently always
> satisfied. In the future should the kernel become mapped we will need to
> cover exception handling code with a wired entry anyway such that TLB
> exception handlers don't themselves trigger TLB exceptions, so the
> constraint should be satisfied there too.

 All error exception handlers run from (C)KSEG1 and with (X)KUSEG forcibly 
unmapped, so a TLB exception could only ever happen with an access to the 
kernel stack or static data located in (C)KSEG2 or XKSEG.  I think this 
can be easily avoided, and actually should, to avoid cascading errors.

 Isn't the reverse a problem though, i.e. getting an error exception while 
running a TLB exception handler and consequently getting the value stashed 
in CP0.ErrorEPC clobbered?  Or do we assume all error exceptions are fatal 
and the kernel shall panic without ever getting back?

  Maciej

  reply	other threads:[~2017-06-15 17:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-02 22:38 [PATCH 0/6] MIPS: TLB exception handler fixes & optimisation Paul Burton
2017-06-02 22:38 ` Paul Burton
2017-06-02 22:38 ` [PATCH 1/6] MIPS: Add CPU shared FTLB feature detection Paul Burton
2017-06-02 22:38   ` Paul Burton
2017-06-02 22:38 ` [PATCH 2/6] MIPS: Handle tlbex-tlbp race condition Paul Burton
2017-06-02 22:38   ` Paul Burton
2017-06-02 22:38 ` [PATCH 3/6] MIPS: Allow storing pgd in C0_CONTEXT for MIPSr6 Paul Burton
2017-06-02 22:38   ` Paul Burton
2017-06-02 22:38 ` [PATCH 4/6] MIPS: Use current_cpu_type() in m4kc_tlbp_war() Paul Burton
2017-06-02 22:38   ` Paul Burton
2017-06-02 22:38 ` [PATCH 5/6] MIPS: tlbex: Use ErrorEPC as scratch when KScratch isn't available Paul Burton
2017-06-02 22:38   ` Paul Burton
2017-06-15 17:27   ` Maciej W. Rozycki [this message]
2017-06-15 17:27     ` Maciej W. Rozycki
2017-06-28 15:25     ` Ralf Baechle
2017-06-29 16:39       ` Maciej W. Rozycki
2017-06-29 16:39         ` Maciej W. Rozycki
2017-06-02 22:38 ` [PATCH 6/6] MIPS: tlbex: Remove struct work_registers Paul Burton
2017-06-02 22:38   ` Paul Burton

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=alpine.DEB.2.00.1706151806310.23046@tp.orcam.me.uk \
    --to=macro@imgtec.com \
    --cc=linux-mips@linux-mips.org \
    --cc=paul.burton@imgtec.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.