From: Ralf Baechle <ralf@linux-mips.org>
To: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Cc: linux-mips@linux-mips.org, david.daney@cavium.com,
cernekee@gmail.com, linux-kernel@vger.kernel.org,
macro@codesourcery.com, markos.chandras@imgtec.com,
kumba@gentoo.org
Subject: Re: [PATCH] MIPS: bugfix of local_r4k_flush_icache_range - added L2 flush
Date: Wed, 10 Jun 2015 12:28:05 +0200 [thread overview]
Message-ID: <20150610102805.GF2753@linux-mips.org> (raw)
In-Reply-To: <20150528203724.28800.63700.stgit@ubuntu-yegoshin>
On Thu, May 28, 2015 at 01:37:24PM -0700, Leonid Yegoshin wrote:
> This function is used to flush code used in NMI and EJTAG debug exceptions.
> However, during that exceptions the Status.ERL bit is set, which means
> that code runs as UNCACHABLE. So, flush code down to memory is needed.
>
> Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
> ---
> arch/mips/mm/c-r4k.c | 10 +---------
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
> index 0dbb65a51ce5..9f0299bb9a2a 100644
> --- a/arch/mips/mm/c-r4k.c
> +++ b/arch/mips/mm/c-r4k.c
> @@ -666,17 +666,9 @@ static inline void local_r4k_flush_icache_range(unsigned long start, unsigned lo
> break;
> }
> }
> -#ifdef CONFIG_EVA
> - /*
> - * Due to all possible segment mappings, there might cache aliases
> - * caused by the bootloader being in non-EVA mode, and the CPU switching
> - * to EVA during early kernel init. It's best to flush the scache
> - * to avoid having secondary cores fetching stale data and lead to
> - * kernel crashes.
> - */
> +
> bc_wback_inv(start, (end - start));
> __sync();
> -#endif
> }
I was wondering why there was a cache flush at all so I dove into git
history and found:
commit 4676f9359fa5190ee6f42bbf2c27d28beb14d26a
Author: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Date: Tue Jan 21 09:48:48 2014 +0000
MIPS: mm: c-r4k: Flush scache to avoid cache aliases
There is a chance for the secondary cache to have memory
aliases. This can happen if the bootloader is in a non-EVA mode
(or even in EVA mode but with different mapping from the kernel)
and the kernel switching to EVA afterwards. It's best to flush
the icache to avoid having the secondary CPUs fetching stale
data from it.
Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
flush_icache_range() really only is meant to deal with I-cache coherency
issues as they appear during normal kernel operation, that is code is
modified and will be executed from RAM. I doesn't know about aliases
and it's not meant to know.
As I understand you only need this on startup. Making this function work
for your special use results in a performance penalty for every other user
of this function.
How about reverting this commit and calling __flush_cache_all() to
make sure your kernel code gets flushed out to the other end of the
universe - or memory, what ever comes first?
Ralf
next prev parent reply other threads:[~2015-06-10 10:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-28 20:37 [PATCH] MIPS: bugfix of local_r4k_flush_icache_range - added L2 flush Leonid Yegoshin
2015-06-10 10:28 ` Ralf Baechle [this message]
2015-06-10 20:00 ` Leonid Yegoshin
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=20150610102805.GF2753@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=Leonid.Yegoshin@imgtec.com \
--cc=cernekee@gmail.com \
--cc=david.daney@cavium.com \
--cc=kumba@gentoo.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=macro@codesourcery.com \
--cc=markos.chandras@imgtec.com \
/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