From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54789) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiqOb-0006aH-BF for qemu-devel@nongnu.org; Thu, 05 Jan 2012 11:42:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RiqOa-000603-2b for qemu-devel@nongnu.org; Thu, 05 Jan 2012 11:42:29 -0500 Message-ID: <4F05D299.8090209@suse.de> Date: Thu, 05 Jan 2012 17:40:57 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1318895545-24861-1-git-send-email-agraf@suse.de> <4F058C6C.9000508@web.de> <7B22C578-9878-4331-B8D5-4E89C78AAFD0@suse.de> <4F05C92A.9020107@web.de> In-Reply-To: <4F05C92A.9020107@web.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] PPC: Bump qemu-system-ppc to 64-bit physical address space List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Avi Kivity Am 05.01.2012 17:00, schrieb Andreas F=E4rber: > Am 05.01.2012 16:52, schrieb Alexander Graf: >> >> On 05.01.2012, at 12:41, Andreas F=E4rber wrote: >> >>> Am 18.10.2011 01:52, schrieb Alexander Graf: >>>> Some 32-bit PPC CPUs can use up to 36 bit of physicall address space= . >>>> Treat them accordingly in the qemu-system-ppc binary type. >>> >>> This change broke the prep machine. :( >>> >>> With -nographic I see: >>> >>> ERROR: BUG caught... >>> BIOS execution exception >>> nip=3D0x05800000 msr=3D0x00002000 dar=3D0x00000000 dsisr=3D0x00000000 >>> Stopping execution >>>> diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h >>>> index 8e5c85c..f36f375 100644 >>>> --- a/target-ppc/cpu.h >>>> +++ b/target-ppc/cpu.h >>>> @@ -66,7 +66,7 @@ >>>> #define TARGET_PAGE_BITS 12 >>>> #endif /* defined(TARGET_PPCEMB) */ >>>> >>>> -#define TARGET_PHYS_ADDR_SPACE_BITS 32 >>>> +#define TARGET_PHYS_ADDR_SPACE_BITS 36 >>> >>> If I revert this part, previous behavior is restored. >>> >>> So it's not about libhw64 or target_phys_addr_t. >>> >>> Any idea? Is 6xx TLB maybe unable to cope with the larger address spa= ce? >>> Or is this an OHW limitation? >> >> That is very confusing tbh. >=20 > It is... Having fixed Avi's Memory API conversion, despite reverting th= e > phys addr space bits as above I get the same breakage again. > Bisecting had clearly pointed out this change. I'll try if bisecting > with the Memory API patch on top gives any new conclusions. Yep, new suspect: 0fb56ffc5edd66f12ccfc0d71af5f9c79c0a2612 is the first bad commit commit 0fb56ffc5edd66f12ccfc0d71af5f9c79c0a2612 Author: Blue Swirl Date: Sat Oct 15 07:57:49 2011 +0000 m48t59: drop obsolete address base arithmetic Remove now incorrect address base arithmetic, missed by 9936d6e42392f1440505dfa9df065eabd251cadf. Fixes Sparc64 boot. Signed-off-by: Blue Swirl :040000 040000 5a38b3f01bb5afd29660755df2622fcf6d5397ce 5a54e03e2d8af7e4a2e9254ae83b0191730e5ee1 M hw with MemoryRegion fix on top. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg