qemu-ppc
[Top][All Lists]
Advanced

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

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


From: Mark Cave-Ayland
Subject: Re: [Qemu-ppc] [Qemu-devel] BookE MMU question
Date: Sun, 20 Aug 2017 23:48:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

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.



reply via email to

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