From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ripm1-0004oH-C2 for qemu-devel@nongnu.org; Thu, 05 Jan 2012 11:02:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Riplv-0006Df-Nw for qemu-devel@nongnu.org; Thu, 05 Jan 2012 11:02:37 -0500 Message-ID: <4F05C92A.9020107@web.de> Date: Thu, 05 Jan 2012 17:00:42 +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> In-Reply-To: <7B22C578-9878-4331-B8D5-4E89C78AAFD0@suse.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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 16:52, schrieb Alexander Graf: > > On 05.01.2012, at 12:41, Andreas Färber 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=0x05800000 msr=0x00002000 dar=0x00000000 dsisr=0x00000000 >> Stopping execution >> >>> Signed-off-by: Alexander Graf >>> --- >>> configure | 2 +- >>> target-ppc/cpu.h | 2 +- >>> 2 files changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/configure b/configure >>> index 9b4fe34..3bdb556 100755 >>> --- a/configure >>> +++ b/configure >>> @@ -3276,7 +3276,7 @@ case "$target_arch2" in >>> ;; >>> ppc) >>> gdb_xml_files="power-core.xml power-fpu.xml power-altivec.xml power-spe.xml" >>> - target_phys_bits=32 >>> + target_phys_bits=64 >>> target_nptl="yes" >>> target_libs_softmmu="$fdt_libs" >>> ;; >> >>> 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 space? >> Or is this an OHW limitation? > > That is very confusing tbh. It is... Having fixed Avi's Memory API conversion, despite reverting the 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. Andreas