On 20/08/17 22:59, BALATON Zoltan wrote: >> 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'm slightly confused here as I thought you'd said you changed the order of the mappings? But if its the first entry then I presume you mean we're back to this one, which is definitely the first mapping according to the source. ppcemb_tlb_check: TLB 0 address ff7fd648 PID 0 <=> ff7f7000 fffff000 03b mmubooke_check_tlb: TLB entry not found [KRN] map_region(007f7000, ff7f7000, 00009000, 081b): [KRN] TLB00: 007f7000 - 007f7fff : ff7f7000 - ff7f7fff: In that case the working is as follows: - You request a region of size 0x9000 - map_region() rounds this up to the next biggest size from allowable_pages() which is 64KB (0xffff) with allowable_pages.code == 0x30 - The 0x30 code (which indicates the page size) is encoded into the first tlbwe instruction The first thing I'd check is to follow through QEMU's tlbwe and make sure that the 0x30 gets decoded correctly back to a TLB size of 0x10000 as indicated by allowable_pages - at the moment it looks as if QEMU is interpreting the 0x30 as a page size of 0x1000 instead. ATB, Mark.
