[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: Mon, 21 Aug 2017 00:57:50 +0200 (CEST)
User-agent: Alpine 2.21 (BSF 202 2017-01-01)

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

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


reply via email to

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