PPC: Bump qemu-system-ppc to 64-bit physical address space

Submitted by Alexander Graf on Oct. 17, 2011, 11:52 p.m.

Details

Message ID 1318895545-24861-1-git-send-email-agraf@suse.de
State New
Headers show

Commit Message

Alexander Graf Oct. 17, 2011, 11:52 p.m.
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(-)

Comments

Andreas Färber Oct. 18, 2011, 9:36 a.m.
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) */
Alexander Graf Oct. 20, 2011, 5:13 p.m.
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
Andreas Färber Jan. 5, 2012, 11:41 a.m.
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) */
Alexander Graf Jan. 5, 2012, 3:52 p.m.
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
Andreas Färber Jan. 5, 2012, 4 p.m.
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
Andreas Färber Jan. 5, 2012, 4:40 p.m.
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

Patch hide | download patch | download mbox

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) */