From: David Daney <ddaney.cavm@gmail.com>
To: "Maciej W. Rozycki" <macro@imgtec.com>, Huacai Chen <chenhc@lemote.com>
Cc: Ralf Baechle <ralf@linux-mips.org>,
Aurelien Jarno <aurelien@aurel32.net>,
"Steven J . Hill" <Steven.Hill@imgtec.com>,
linux-mips@linux-mips.org, Fuxin Zhang <zhangfx@lemote.com>,
Zhangjin Wu <wuzhangjin@gmail.com>,
stable@kernel.org
Subject: Re: [PATCH] MIPS: tlbex: Fix bugs in tlbchange handler
Date: Wed, 24 Feb 2016 17:06:10 -0800 [thread overview]
Message-ID: <56CE5382.4090800@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1602250029390.15885@tp.orcam.me.uk>
On 02/24/2016 04:40 PM, Maciej W. Rozycki wrote:
> On Wed, 24 Feb 2016, Huacai Chen wrote:
>
>> If a tlb miss triggered when EXL=1, tlb refill exception is treated as
>> tlb invalid exception, so tlbp may fails. In this situation, CP0_Index
>> register doesn't contain a valid value. This may not be a problem for
>> VTLB since it is fully-associative. However, FTLB is set-associative so
>> not every tlb entry is valid for a specific address. Thus, we should
>> use tlbwr instead of tlbwi when tlbp fails.
>
> Can you please explain exactly why this change is needed? You're
> changing pretty generic code which has worked since forever. So why is a
> change suddenly needed? Our kernel entry/exit code has been written such
> that no mapped memory is accessed with EXL=1 so no TLB exception is
> expected to ever happen in these circumstances. So what's your scenario
> you mean to address? Your patch description does not explain it.
>
I asked this exact same question back on Jan. 26, when the patch was
previously posted.
No answer was given, all we got was the same thing again with no
explanation.
David Daney
>> @@ -1913,7 +1935,14 @@ build_r4000_tlbchange_handler_tail(u32 **p, struct uasm_label **l,
>> uasm_i_ori(p, ptr, ptr, sizeof(pte_t));
>> uasm_i_xori(p, ptr, ptr, sizeof(pte_t));
>> build_update_entries(p, tmp, ptr);
>> + uasm_i_mfc0(p, ptr, C0_INDEX);
>> + uasm_il_bltz(p, r, ptr, label_tail_miss);
>> + uasm_i_nop(p);
>> build_tlb_write_entry(p, l, r, tlb_indexed);
>> + uasm_il_b(p, r, label_leave);
>> + uasm_i_nop(p);
>> + uasm_l_tail_miss(l, *p);
>> + build_tlb_write_entry(p, l, r, tlb_random);
>> uasm_l_leave(l, *p);
>> build_restore_work_registers(p);
>> uasm_i_eret(p); /* return from trap */
>
> Specifically you're causing a performance hit here, which is a fast path,
> for everyone. If you have a scenario that needs this change, then please
> make it conditional on the circumstances and keep the handler unchanged in
> all the other cases.
>
> Maciej
>
>
>
next prev parent reply other threads:[~2016-02-25 1:06 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-24 14:32 [PATCH V3 0/5] MIPS: Loongson: Add Loongson-3A R2 support Huacai Chen
2016-02-24 14:32 ` [PATCH] MIPS: tlbex: Fix bugs in tlbchange handler Huacai Chen
2016-02-25 0:40 ` Maciej W. Rozycki
2016-02-25 0:40 ` Maciej W. Rozycki
2016-02-25 1:06 ` David Daney [this message]
2016-02-25 5:32 ` Huacai Chen
2016-02-25 11:02 ` Maciej W. Rozycki
2016-02-25 12:41 ` Huacai Chen
2016-02-24 14:32 ` [PATCH] MIPS: Introduce cpu_has_coherent_cache feature Huacai Chen
2016-02-25 0:59 ` Maciej W. Rozycki
2016-02-25 0:59 ` Maciej W. Rozycki
2016-02-25 5:36 ` Huacai Chen
2016-02-25 11:16 ` Maciej W. Rozycki
2016-02-25 12:53 ` Huacai Chen
2016-02-26 5:35 ` Huacai Chen
2016-02-26 15:22 ` Maciej W. Rozycki
2016-02-24 14:33 ` [PATCH V3 1/5] MIPS: Loongson: Add Loongson-3A R2 basic support Huacai Chen
2016-02-24 14:33 ` [PATCH V3 2/5] MIPS: Loongson: Invalidate special TLBs when needed Huacai Chen
2016-02-24 14:33 ` [PATCH V3 3/5] MIPS: Loongson-3: Fast TLB refill handler Huacai Chen
2016-02-24 14:33 ` [PATCH V3 4/5] MIPS: Loongson-3: Use cpu_has_coherent_cache feature Huacai Chen
2016-02-24 14:33 ` [PATCH V3 5/5] MIPS: Loongson-3: Introduce CONFIG_LOONGSON3_ENHANCEMENT Huacai Chen
2016-02-25 0:49 ` Maciej W. Rozycki
2016-02-25 0:49 ` Maciej W. Rozycki
2016-02-25 5:41 ` Huacai Chen
2016-02-25 12:25 ` Maciej W. Rozycki
2016-02-25 12:49 ` Huacai Chen
2016-03-01 1:06 ` Maciej W. Rozycki
2016-03-01 2:18 ` Huacai Chen
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=56CE5382.4090800@gmail.com \
--to=ddaney.cavm@gmail.com \
--cc=Steven.Hill@imgtec.com \
--cc=aurelien@aurel32.net \
--cc=chenhc@lemote.com \
--cc=linux-mips@linux-mips.org \
--cc=macro@imgtec.com \
--cc=ralf@linux-mips.org \
--cc=stable@kernel.org \
--cc=wuzhangjin@gmail.com \
--cc=zhangfx@lemote.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