[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [Qemu-devel] [PATCH] PPC: Bump qemu-system-ppc to 64-bit
From: |
Andreas Färber |
Subject: |
Re: [Qemu-ppc] [Qemu-devel] [PATCH] PPC: Bump qemu-system-ppc to 64-bit physical address space |
Date: |
Thu, 05 Jan 2012 17:00:42 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 |
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 <address@hidden>
>>> ---
>>> 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