All of lore.kernel.org
 help / color / mirror / Atom feed
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
>
>
>

  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 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.