qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andreas Färber
Subject: Re: [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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]