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: