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

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

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

Forget this, this was by mistake, we don't even reach this because the 
mapping of 00800000 is already failing. That needs to be fixed first.

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

I've run out of time for now, I'll check this when the first problem is 
solved and this will still be a problem by then.

Thanks,
BALATON Zoltan