[Qemu-devel] [PATCH] PPC: Bump qemu-system-ppc to 64-bit physical address space

[Qemu-devel] [PATCH] PPC: Bump qemu-system-ppc to 64-bit physical address space

[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.

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
 #define TARGET_VIRT_ADDR_SPACE_BITS 32
 
 #endif /* defined (TARGET_PPC64) */
-- 
1.6.0.2

Re: [Qemu-devel] [PATCH] PPC: Bump qemu-system-ppc to 64-bit physical address space

[Andreas Färber]

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


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746, AG Nürnberg

Re: [Qemu-devel] [PATCH] PPC: Bump qemu-system-ppc to 64-bit physical address space

[Alexander Graf]

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

Re: [Qemu-devel] [PATCH] PPC: Bump qemu-system-ppc to 64-bit physical address space

[Andreas Färber]

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

Re: [Qemu-devel] [PATCH] PPC: Bump qemu-system-ppc to 64-bit physical address space

[Alexander Graf]

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

Re: [Qemu-devel] [PATCH] PPC: Bump qemu-system-ppc to 64-bit physical address space

[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
>>
>>> 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

Re: [Qemu-devel] [PATCH] PPC: Bump qemu-system-ppc to 64-bit physical address space

[Andreas Färber]

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

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg