From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52369) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djZAQ-0007oY-D6 for qemu-devel@nongnu.org; Sun, 20 Aug 2017 18:58:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1djZAN-0003ht-9r for qemu-devel@nongnu.org; Sun, 20 Aug 2017 18:58:02 -0400 Date: Mon, 21 Aug 2017 00:57:50 +0200 (CEST) From: BALATON Zoltan In-Reply-To: <24fb125a-de7e-ca18-8ca8-9ab7f2d113d1@ilande.co.uk> Message-ID: References: <0e3383a1-33b5-8238-75e2-48e36b7daea4@adacore.com> <03c6e36f-c79d-3174-772d-5cd361703f7d@ilande.co.uk> <7f4e58b7-7e8e-4e94-8435-861af3103d1c@ilande.co.uk> <24fb125a-de7e-ca18-8ca8-9ab7f2d113d1@ilande.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: [Qemu-devel] [Qemu-ppc] BookE MMU question List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Cave-Ayland Cc: Francois Revol , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, David Gibson 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