[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: BALATON Zoltan
Subject: Re: [Qemu-ppc] [Qemu-devel] BookE MMU question
Date: Sun, 20 Aug 2017 23:59:55 +0200 (CEST)
User-agent: Alpine 2.02 (LMD 1266 2009-07-14)

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 => 

(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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]