Re: [PATCH v3 09/33] nds32: Cache and TLB routines
From: Greentime Hu
Date: Wed Dec 13 2017 - 00:45:52 EST
2017-12-13 10:16 GMT+08:00 Guo Ren <ren_guo@xxxxxxxxx>:
> On Fri, Dec 08, 2017 at 05:11:52PM +0800, Greentime Hu wrote:
>> From: Greentime Hu <greentime@xxxxxxxxxxxxx>
> [...]
>> diff --git a/arch/nds32/mm/cacheflush.c b/arch/nds32/mm/cacheflush.c
> [...]
>> +#ifndef CONFIG_CPU_CACHE_ALIASING
>> +void update_mmu_cache(struct vm_area_struct *vma, unsigned long addr,
>> + pte_t * pte)
> [...]
>> + if (vma->vm_mm == current->active_mm) {
>> +
>> + __nds32__mtsr_dsb(addr, NDS32_SR_TLB_VPN);
>> + __nds32__tlbop_rwr(*pte);
>> + __nds32__isb();
> If there is an interruption between "mtsr_dsb" and "tlbop_rwr" and a
> update_mmu_cache() is invoked again, then an error page mapping is
> set up in your tlb-buffer when tlbop_rwr is excuted from interrupt.
> Because it's another addr in NDS32_SR_TLB_VPN.
>
> It seems that tlb-hardrefill can help build tlb-buffer mapping, why you
> update it in this software way?
>
Hi, Guo Ren:
I think it should be fine if an interruption between mtsr_dsb and
tlbop_rwr because this is a optimization by sw.
The page mapping has been created and it is just not in TLB yet.
What we did is to insert this mapping to TLB by SW thus it can prevent
TLB miss one time.
It will be fine even if TLB miss. HW will walk through page table and
insert this mapping to TLB anyway.
Based on Documentation/cachetlb.txt
5) ``void update_mmu_cache(struct vm_area_struct *vma,
unsigned long address, pte_t *ptep)``
At the end of every page fault, this routine is invoked to
tell the architecture specific code that a translation
now exists at virtual address "address" for address space
"vma->vm_mm", in the software page tables.
A port may use this information in any way it so chooses.
For example, it could use this event to pre-load TLB
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
translations for software managed TLB configurations.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^