From patchwork Mon Jan 10 03:57:17 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bob Breuer X-Patchwork-Id: 78071 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id E338BB70A9 for ; Mon, 10 Jan 2011 14:55:10 +1100 (EST) Received: from localhost ([127.0.0.1]:42635 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pc8lx-0004Km-Hs for incoming@patchwork.ozlabs.org; Sun, 09 Jan 2011 22:50:21 -0500 Received: from [140.186.70.92] (port=44990 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pc8lE-000402-Ts for qemu-devel@nongnu.org; Sun, 09 Jan 2011 22:49:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pc8lD-0000X8-He for qemu-devel@nongnu.org; Sun, 09 Jan 2011 22:49:36 -0500 Received: from mail.mc.net ([209.172.128.24]:52070) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Pc8lD-0000X0-Ba for qemu-devel@nongnu.org; Sun, 09 Jan 2011 22:49:35 -0500 Received: (qmail 17802 invoked by uid 420); 10 Jan 2011 03:49:36 -0000 Received: from unknown (HELO ?127.0.0.1?) (breuerr@209.172.177.18) by mail.mc.net with SMTP; 10 Jan 2011 03:49:36 -0000 Message-ID: <4D2A839D.2050407@mc.net> Date: Sun, 09 Jan 2011 21:57:17 -0600 From: Bob Breuer User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Blue Swirl Subject: Re: [Qemu-devel] Re: phys_page_find bug? References: In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 Cc: qemu-devel , Artyom Tarasenko X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Blue Swirl wrote: > On Mon, Nov 8, 2010 at 6:55 PM, Artyom Tarasenko wrote: > >> On Fri, May 7, 2010 at 6:26 PM, Artyom Tarasenko >> wrote: >> >>> phys_page_find (exec.c) returns sometimes a page for addresses where >>> nothing is connected. >>> >>> One example, done with qemu-system-sparc -M SS-20 >>> >>> ok f13ffff0 2f spacec@ . >>> >>> // The address translates correctly, in cpu_physical_memory_rw >>> // addr== 0xff13ffff0 (where nothing is connected) >>> // but then phys_page_find returns a nonzero and produces >>> >>> Unassigned mem read access of 1 byte to 0000000ff15ffff0 from xxxxx >>> >>> (note the "5" in the line above where "3" is expected) >>> >>> I wonder if this is only true for non-wired addresses, or whether >>> phys_page_find can also >>> find wrong pages for the addresses where something is connected? >>> >>> Or is my assumption is wrong and phys_page_find can return a page for >>> not-connected >>> addresses and the bug is actually in cpu_physical_memory_rw ? >>> >>> Is the qemu algorithm of working with the physical address space >>> described somewhere? >>> >> I tried to switch devices off and found that the bug is triggered by >> registering escc. >> It's harder to debug without escc, so I can't tell whether something >> else is causing >> the problem too. >> >> Is escc addressing somehow special? >> > > I don't think so, except that it lies close to the top of the physical > address space. > > >>> Is the qemu algorithm of working with the physical address space described somewhere? >>> >> I guess no one knows it anymore, since no-one cared to answer within a >> half year :-/. >> > > There's of course good old exec.c, plenty of code and even some comments. ;-) > You can also see this in SS-20 when OBP probes all the sbus slots. Slot 2 with the tcx graphics shows an unexpected address: Unassigned mem read access of 1 byte to 0000000e00000000 from ffd3f5e4 Unassigned mem read access of 1 byte to 0000000e10000000 from ffd3f5e4 Unassigned mem read access of 1 byte to 0000000020200000 from ffd3f5e4 Unassigned mem read access of 1 byte to 0000000e30000000 from ffd3f5e4 The 0202 should be e200 instead. There's two bugs in phys_page_find_alloc(). When the bottom level L2 table is populated with IO_MEM_UNASSIGNED, region_offset is then used for reporting the physical address. First, region_offset may not be aligned to the base address of the L2 region. And second, region_offset won't hold the full 36-bit address on a 32-bit host. It seems that both can be fixed by returning NULL for unassigned addresses from phys_page_find(). All callers already handle a NULL return value. Would this allow any further optimizations to be made? Here's a patch to try: static void tlb_protect_code(ram_addr_t ram_addr); Tested-by: Artyom Tarasenko diff --git a/exec.c b/exec.c index 49c28b1..77b49c8 100644 --- a/exec.c +++ b/exec.c @@ -434,7 +434,11 @@ static PhysPageDesc *phys_page_find_alloc(target_phys_addr_t index, int alloc) static inline PhysPageDesc *phys_page_find(target_phys_addr_t index) { - return phys_page_find_alloc(index, 0); + PhysPageDesc *pd = phys_page_find_alloc(index, 0); + if (pd && pd->phys_offset == IO_MEM_UNASSIGNED) { + return NULL; + } + return pd; }