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 <ag...@suse.de> >>> --- >>> 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