[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-mips
Subject: Re: [PATCH] MIPS: tlbex: fix a missing statement for HUGETLB
From: James Hogan <james.hogan () imgtec ! com>
Date: 2014-08-04 13:10:35
Message-ID: 53DF864B.6000702 () imgtec ! com
[Download RAW message or body]
On 04/08/14 14:05, Aurelien Jarno wrote:
> On Mon, Aug 04, 2014 at 11:08:50AM +0100, James Hogan wrote:
>> Hi Aurelien,
>>
>> On 02/08/14 22:35, Aurelien Jarno wrote:
>>> On Thu, Jul 31, 2014 at 10:33:55AM -0700, David Daney wrote:
>>>> 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);
>>>
>>> This patch fixes the issue, thanks. That said it doesn't look fully
>>> correct. The test should be done the same way as for
>>> build_fast_tlb_refill_handler. For example the fast handler is not
>>> called on a 32-bit machine with bbit instructions, so it would need
>>> to reload K0.
>>
>> In the non fast case build_is_huge_pte() will still use bbit1 if
>> available after restoring K0, and I don't think the bbit1 would clobber
>> K0 when the branch is taken, so I think the test for !use_bbit_insns()
>> is correct.
>>
> Oh you are right! Therefore this second patch is:
>
> Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>
Likewise:
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Cheers
James
> Tested-by: Aurelien Jarno <aurelien@aurel32.net>
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic