From: "Andreas Färber" <andreas.faerber@web.de>
To: Alexander Graf <agraf@suse.de>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Avi Kivity <avi@redhat.com>
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 [thread overview]
Message-ID: <4F05C92A.9020107@web.de> (raw)
In-Reply-To: <7B22C578-9878-4331-B8D5-4E89C78AAFD0@suse.de>
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
next prev parent reply other threads:[~2012-01-05 16:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-17 23:52 [Qemu-devel] [PATCH] PPC: Bump qemu-system-ppc to 64-bit physical address space Alexander Graf
2011-10-18 9:36 ` Andreas Färber
2011-10-20 17:13 ` Alexander Graf
2012-01-05 11:41 ` Andreas Färber
2012-01-05 15:52 ` Alexander Graf
2012-01-05 16:00 ` Andreas Färber [this message]
2012-01-05 16:40 ` Andreas Färber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F05C92A.9020107@web.de \
--to=andreas.faerber@web.de \
--cc=agraf@suse.de \
--cc=avi@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).