uwe@ptc.spbu.ru wrote:

> Can someone who is more familiar with sh4 pmap take a look at this PR?

I'm not familiar with SH, but it looks VIPT
(virtually indexed and physical tagged) cache
handling problem, which is also annoying on mips.

>> I've traced it a bit further.  What happens is that we see an infinite
>> recurring tlb miss for the instruction we are stuck at:
>> 
>>   0x20690a9c:     mov.l   @r4, r1         ! where r4 == 0x206a0fcc
>> 
>> Some debugging printfs show that the following sequence of calls is
>> repeated over and over:
>> 
>>   tlbinv: va=20690000 (from pmap_remove)
>> 
>>   _pteld: va=20690a9c flags=1 -> entry == 0
>> 
>>   tlbupd: va=20690000 pte=0c6f1158 (from pmap_enter)
>>   tlbinv: va=20690000 (from sh4_tlb_update)
>> 
>>   _pteld: va=20690a9c flags=1 -> entry=0c6f1158 =V
>>   tlbupd: va=20690a9c pte=0c6f1158 (from __pmap_pte_load)
>>   tlbinv: va=20690a9c (from sh4_tlb_update)

Currently __pmap_pv_enter() allows only one P-V mappings
if CPU has virtual indexed cache (i.e. in CPU_IS_SH4 case)
to avoid virtual cache aliases.
(mentioned as "cache synonym problem" in the programming manual)

But in the above case, one physical address is being mapped
to VA where the program is running (0x20690000) and
the same PA is need to be mapped to another page (0x206a0000).
But _pmap_pv_enter() removes existing mapping so the VA where
the program running becomes invalid and it causes the next page fault
after pmap_enter() returns, then infinite loop, I guess.

Maybe we should check virtual cache index in pmap_pv_enter() and
allow multiple mappings if VA pages being mapped have the same
virtual indexes like mips pmap? Or mapping the pages uncached?
Or MI VM (or ld.elf_so) should be fixed to avoid such mappings?
---
Izumi Tsutsui