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

[BALATON Zoltan <balaton@eik.bme.hu>]

On Sun, 20 Aug 2017, Mark Cave-Ayland wrote:
> 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.

I've tried that but it only confirmed what I thought. This is the first 
map_region call so nothing is allocated yet and it just picks the first 
slot:

[KRN] i = 2, allowable_pages[i].mask = 000fffff; tlb_info ffffffff:ffffffff => 7fffffff:ffffffff

(The numbers after tlb_info are bitmap[0]:bitmap[1] before and after the 
alloc_tlb() call.) So this looks OK just does not work on QEMU and I don't 
know why it works on real hardware (or if it works there at all but I 
assume it does).

I've also tried to change mmubooke_create_initial_mapping_uboot() in 
sam460ex.c to use another TLB slot than 0 for the initial mapping hoping 
it may avoid the problem but that does not work because U-Boot clears TLB 
slots 1-63 so it has to be slot 0. Because of this I think it cannot be 
another slot on real hardware either and it probably works due to caching 
TLB entries in shadow TLB until the isync call at the end of mmu_init(). 
How could that be matched in QEMU?