All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Daney <ddaney@caviumnetworks.com>
To: James Hogan <james.hogan@imgtec.com>
Cc: Huacai Chen <chenhc@lemote.com>,
	James Hogan <james@albanarts.com>,
	"Linux MIPS Mailing List" <linux-mips@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	John Crispin <john@phrozen.org>,
	"Steven J. Hill" <Steven.Hill@imgtec.com>,
	Fuxin Zhang <zhangfx@lemote.com>,
	Zhangjin Wu <wuzhangjin@gmail.com>,
	Binbin Zhou <zhoubb@lemote.com>, stable <stable@vger.kernel.org>
Subject: Re: [PATCH] MIPS: tlbex: fix a missing statement for HUGETLB
Date: Thu, 31 Jul 2014 10:33:55 -0700	[thread overview]
Message-ID: <53DA7E03.9090306@caviumnetworks.com> (raw)
In-Reply-To: <53DA2E66.20200@imgtec.com>

On 07/31/2014 04:54 AM, James Hogan wrote:
> Hi,
>
> On 31/07/14 02:13, David Daney wrote:
>> On 07/30/2014 05:48 PM, Huacai Chen wrote:
>>> For non-Octeon CPU, htlb_info.huge_pte is equal to K0, but I don't
>>> know much about Octeon. So I think you know whether we should use K0
>>>   or htlb_info.huge_pte here, since you are the original author.
>>>
>>
>> This is why I requested that somebody show me a disassembly of the
>> faulty handler.  I cannot tell where the problem is unless I see that.
>>
>> Really I think the problem is in build_is_huge_pte(), where we are
>> clobbering 'tmp' which is K0.
>>
>> So you could reload tmp/K0 in build_is_huge_pte().
>
> Here's the difference with this patch (using k0) on an Octeon I have to
> hand, with some slightly munged offsets for nicer diffing:
>
> #define _PAGE_PRESENT_SHIFT 0
> #define _PAGE_READ_SHIFT 0
> #define _PAGE_WRITE_SHIFT 1
> #define _PAGE_ACCESSED_SHIFT 2
> #define _PAGE_MODIFIED_SHIFT 3
> #define _PAGE_HUGE_SHIFT 4
> #define _PAGE_SPLITTING_SHIFT 5
> #define _PAGE_NO_EXEC_SHIFT 6
> #define _PAGE_NO_READ_SHIFT 7
> #define _PAGE_GLOBAL_SHIFT 8
> #define _PAGE_VALID_SHIFT 9
> #define _PAGE_DIRTY_SHIFT 10
> #define _PFN_SHIFT 14
>
>   00000000 <r4000_tlb_refill>:
> +   0:	df7a0000 	ld	k0,0(k1)

Completely redundant, it is not used and then clobbered...

>      4:	00210a3a 	dror	at,at,0x8
>      8:	40a11000 	dmtc0	at,c0_entrylo0
>      c:	64214000 	daddiu	at,at,16384
>     10:	40a11800 	dmtc0	at,c0_entrylo1
>     14:	3c1a001f 	lui	k0,0x1f

... here.

>     18:	375ae000 	ori	k0,k0,0xe000
>     1c:	409a2800 	mtc0	k0,c0_pagemask
>     20:	000000c0 	ehb
>     24:	42000006 	tlbwr
>     28:	40802800 	mtc0	zero,c0_pagemask
> -  28:	1000002e 	b	e4 <r4000_tlb_refill+0xe4>
> +  2c:	1000002d 	b	e4 <r4000_tlb_refill+0xe4>
>     30:	4021f802 	dmfc0	at,$31,2
> -  30:	07400019 	bltz	k0,98 <r4000_tlb_refill+0x98>
> +  34:	07400018 	bltz	k0,98 <r4000_tlb_refill+0x98>
>     38:	3c1b81da 	lui	k1,0x81da
>     3c:	3c1b8113 	lui	k1,0x8113
> -  3c:	277b7ef0 	addiu	k1,k1,32496
> +  40:	277b7f00 	addiu	k1,k1,32512
>     44:	03600008 	jr	k1
>     48:	4021f802 	dmfc0	at,$31,2
>   	...
>     80:	403a4000 	dmfc0	k0,c0_badvaddr
>     84:	403bf803 	dmfc0	k1,$31,3
>     88:	40a1f802 	dmtc0	at,$31,2
>     8c:	001a0a3e 	dsrl32	at,k0,0x8
> -  90:	1420ffe7 	bnez	at,30 <r4000_tlb_refill+0x30>
> +  90:	1420ffe8 	bnez	at,34 <r4000_tlb_refill+0x34>
>     94:	001a0efa 	dsrl	at,k0,0x1b
>     98:	30211ff8 	andi	at,at,0x1ff8
>     9c:	7c3bda0a 	ldx	k1,k1(at)
>     a0:	001a0cba 	dsrl	at,k0,0x12
>     a4:	30210ff8 	andi	at,at,0xff8
>     a8:	403aa000 	dmfc0	k0,c0_xcontext
>     ac:	7c3b0a0a 	ldx	at,k1(at)
>     b0:	335a0ff0 	andi	k0,k0,0xff0
>     b4:	e824ffd2 	bbit1	at,0x4,0 <r4000_tlb_refill>
>     b8:	00000000 	nop
>     bc:	7c3ada0a 	ldx	k1,k0(at)
>     c0:	675a0008 	daddiu	k0,k0,8
>     c4:	7c3ad20a 	ldx	k0,k0(at)
>     c8:	003bda3a 	dror	k1,k1,0x8
>     cc:	40bb1000 	dmtc0	k1,c0_entrylo0
>     d0:	003ad23a 	dror	k0,k0,0x8
>     d4:	40ba1800 	dmtc0	k0,c0_entrylo1
>     d8:	4021f802 	dmfc0	at,$31,2
>     dc:	000000c0 	ehb
>     e0:	42000006 	tlbwr
>     e4:	42000018 	eret
>
>
> b4 is apparently where it branches back to the huge page case at the
> beginning. In that case the at register (htlb_info.huge_pte) is set to
> *(k1+at) instead of *(k1), so loading to htlb_info.huge_pte instead of
> k0 would I think be bad and change the behaviour. So forget my suggestion!
>
> On the other hand loading the pte to k0 is redundant when
> build_fast_tlb_refill_handler is used (which depends on bbit1), and also
> in the other case if bbit1 is available since it won't get clobbered by
> build_is_huge_pte().
>
> Maybe the reload should simply be conditional on !use_bbit_insns()?
>

That was kind of my suggestion.  What happens if you do something like 
(untested):

--- a/arch/mips/mm/tlbex.c
+++ b/arch/mips/mm/tlbex.c
@@ -716,6 +716,7 @@ build_is_huge_pte(u32 **p, struct uasm_reloc **r, 
unsigned int tmp,
         } else {
                 uasm_i_andi(p, tmp, tmp, _PAGE_HUGE);
                 uasm_il_bnez(p, r, tmp, lid);
+               UASM_i_LW(p, tmp, 0, pmd);
         }
  }

or

diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c
index f99ec587..341add1 100644
--- a/arch/mips/mm/tlbex.c
+++ b/arch/mips/mm/tlbex.c
@@ -1299,6 +1299,8 @@ static void build_r4000_tlb_refill_handler(void)
         }
  #ifdef CONFIG_MIPS_HUGE_TLB_SUPPORT
         uasm_l_tlb_huge_update(&l, p);
+       if (!use_bbit_insns())
+               UASM_i_LW(&p, K0, 0, K1);
         build_huge_update_entries(&p, htlb_info.huge_pte, K1);
         build_huge_tlb_write_entry(&p, &l, &r, K0, tlb_random,
                                    htlb_info.restore_scratch);


> Cheers
> James
>
>

  reply	other threads:[~2014-07-31 17:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-29  6:54 [PATCH] MIPS: tlbex: fix a missing statement for HUGETLB Huacai Chen
2014-07-29  6:54 ` Huacai Chen
2014-07-30 16:37 ` Aurelien Jarno
2014-07-30 21:41 ` James Hogan
2014-07-30 21:44   ` David Daney
2014-07-30 21:44     ` David Daney
2014-07-31  0:48     ` Huacai Chen
2014-07-31  1:13       ` David Daney
2014-07-31 11:54         ` James Hogan
2014-07-31 17:33           ` David Daney [this message]
2014-08-02 21:35             ` Aurelien Jarno
2014-08-04 10:08               ` James Hogan
2014-08-04 13:05                 ` Aurelien Jarno
2014-08-04 13:10                   ` James Hogan
2014-08-05  7:09                     ` Huacai Chen
2014-08-06 16:27                       ` Ralf Baechle

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=53DA7E03.9090306@caviumnetworks.com \
    --to=ddaney@caviumnetworks.com \
    --cc=Steven.Hill@imgtec.com \
    --cc=chenhc@lemote.com \
    --cc=james.hogan@imgtec.com \
    --cc=james@albanarts.com \
    --cc=john@phrozen.org \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=stable@vger.kernel.org \
    --cc=wuzhangjin@gmail.com \
    --cc=zhangfx@lemote.com \
    --cc=zhoubb@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.