| Message ID | 1318895545-24861-1-git-send-email-agraf@suse.de |
|---|---|
| State | New |
| Headers | show |
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. physical > Signed-off-by: Alexander Graf <agraf@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" > ;; I've found this very unintuitive for the new targets I'm preparing. Could we use the real target_phys_bits=36 here and later on ceil this to 32/64 before using it for libhw${target_phys_bits}? Andreas > 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 > #define TARGET_VIRT_ADDR_SPACE_BITS 32 > > #endif /* defined (TARGET_PPC64) */
On 18.10.2011, at 02:36, 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. > > physical > >> Signed-off-by: Alexander Graf <agraf@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" >> ;; > > I've found this very unintuitive for the new targets I'm preparing. > Could we use the real target_phys_bits=36 here and later on ceil this to > 32/64 before using it for libhw${target_phys_bits}? I'd rather just always make target_phys_bits = 64 and be done with it. Alex
Dear Mr. ppc, 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 <agraf@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? Still bisecting another regression... Andreas > #define TARGET_VIRT_ADDR_SPACE_BITS 32 > > #endif /* defined (TARGET_PPC64) */
On 05.01.2012, at 12:41, Andreas Färber wrote: > Dear Mr. ppc, > > 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 <agraf@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. Does qemu-system-ppc64 work with -M prep and -cpu <something old>? The constant is only used for QEMU's internal TLB. Alex
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 <agraf@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
Am 05.01.2012 17:00, schrieb Andreas Färber: > 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 >>>> 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. Yep, new suspect: 0fb56ffc5edd66f12ccfc0d71af5f9c79c0a2612 is the first bad commit commit 0fb56ffc5edd66f12ccfc0d71af5f9c79c0a2612 Author: Blue Swirl <blauwirbel@gmail.com> 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 <blauwirbel@gmail.com> :040000 040000 5a38b3f01bb5afd29660755df2622fcf6d5397ce 5a54e03e2d8af7e4a2e9254ae83b0191730e5ee1 M hw with MemoryRegion fix on top. Andreas
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 #define TARGET_VIRT_ADDR_SPACE_BITS 32 #endif /* defined (TARGET_PPC64) */
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. Signed-off-by: Alexander Graf <agraf@suse.de> --- configure | 2 +- target-ppc/cpu.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)