Re: [Qemu-devel] [Qemu-ppc] BookE MMU question

[Mark Cave-Ayland]

On 20/08/17 14:35, BALATON Zoltan wrote:

> Anyway, this makes more sense because if the TLB 0 entry is replaced
> like the above log shows then there will be no mapping for the ff7fd648
> address until the next map_region call maps it. On real hardware this
> seems to work but on QEMU this causes an exception. Any idea why? My
> guesses are that on real hardware either the initial TLB entries are
> different so this call does not replace the entry used to look up
> addresses needed for running this code or the TLB changes are not
> effective until the last isync is executed to flush shadow TLB regs
> which still contain mappings that allow this code to run. To confirm
> this I'd need logs from real hardware though.
> 
> Any idea how to fix this problem?

Just glancing at the code again it looks like the choice of slot is
determined by alloc_tlb(). It seems there are 64 TLB slots stored in
tlb_info as 2 x 32-bit bitmaps where a 1 bit indicates the slot is free
and a 0 bit indicates the slot is in use.

>From alloc_tlb() you can see that it uses clz (count leading zeros) in
order to locate the next free TLB slot in the bitmap, returning the slot
number as an integer (tlb) which is then passed into tlbwe.

So I'd suggest adding debugging to alloc_tlb() to find out why TLB slot
0 is being chosen again for the 0x80000000 mapping even though
free_tlb() hasn't been called for that entry.

>> And of course read the BookE specification to understand exactly what
>> types of TLB mapping are available, particularly with respect to page
>> size.
> 
> That's what I wanted to avoid and hoped someone already with this
> knowledge can spot the problem easily. I don't have much time to spend
> on learning everything about PPC features and their QEMU implementation
> so I rather asked.

Sometimes when debugging MMU issues there is no other choice :)


ATB,

Mark.