From: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [PATCH v8 0/5] Mac Old World ROM experiment (ppc/mac_* clean ups and loading binary ROM)
Date: Sat, 17 Oct 2020 19:44:29 +0200 [thread overview]
Message-ID: <6598b187-7936-563c-c06b-cb4315fa4cc1@amsat.org> (raw)
In-Reply-To: <edb86311-6093-9776-a81-17ee8205a6c@eik.bme.hu>
On 10/17/20 6:39 PM, BALATON Zoltan via wrote:
> On Fri, 16 Oct 2020, Philippe Mathieu-Daudé wrote:
>> On 10/16/20 11:58 AM, Mark Cave-Ayland wrote:
>>> On 16/10/2020 00:47, BALATON Zoltan via wrote:
>>>
>>>> This is the cut down version of the earlier series omitting unfinished
>>>> patches that I plan to rework later and rebased to Mark's qemu-macppc
>>>> branch. Compared to v7 the only change is the cast to (target_ulong)
>>>> from (uint32_t) as requested by Mark in patch 1.
>>>
>>> FWIW the reason for suggesting the cast to target_ulong is so that
>>> the same code works for both qemu-system-ppc and qemu-system-ppc64.
>>> For qemu-system-ppc that should correctly drop the sign extension
>>> from 32-bit, whilst still allowing someone to load a 64-bit ELF into
>>> qemu-system-ppc64 if requested.
>>
>> IMO this is part of a bigger design problem. Not all
>> machines main bus is 64-bit. I did some experiments
>> but changing that involves a lot of work.
>
> Did not want to reply to this to not bring it to your attention before
> patch gets in finally but it's too late...
>
> Not sure what you refer to
I refer to having machines with a N-bit main bus using a N-bit main bus
(currently all main busses are 64-bit wide).
Some 32-bit machines have access to 64-bit busses, some don't.
I have been wondering about it because of the AVR CPU which
uses a pair of busses, each less than 32-bit.
If one day I can finish my work there, the Old World mac might
benefit from it.
> but in this particular case the problem only
> seems to be load_elf loading 32 bit ELF files returning sign extended 64
> bit address which looks bogus but since this function is widely used I
> did not feel confident enough to propose a patch to load_elf.
>
> By the way, also the parameters of load_elf could take a clean up to
> remove all the mostly NULL values as I've pointed out before:
>
> https://lists.nongnu.org/archive/html/qemu-devel/2019-01/msg03427.html
>
> but all this could wait until later, these don't seem to be urgent
> problems to prevent moving mac machines forward now and could all be
> addressen in separate elf loading series. So just note the problem and
> move on for now please.
>
> Reagards.
> BALATON Zoltan
prev parent reply other threads:[~2020-10-17 17:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-15 23:47 [PATCH v8 0/5] Mac Old World ROM experiment (ppc/mac_* clean ups and loading binary ROM) BALATON Zoltan via
2020-10-15 23:47 ` [PATCH v8 4/5] mac_oldworld: Drop some variables BALATON Zoltan via
2020-10-15 23:47 ` [PATCH v8 1/5] mac_oldworld: Allow loading binary ROM image BALATON Zoltan via
2020-10-15 23:47 ` [PATCH v8 5/5] mac_oldworld: Change PCI address of macio to match real hardware BALATON Zoltan via
2020-10-15 23:47 ` [PATCH v8 2/5] mac_newworld: Allow loading binary ROM image BALATON Zoltan via
2020-10-15 23:47 ` [PATCH v8 3/5] mac_oldworld: Drop a variable, use get_system_memory() directly BALATON Zoltan via
2020-10-16 9:58 ` [PATCH v8 0/5] Mac Old World ROM experiment (ppc/mac_* clean ups and loading binary ROM) Mark Cave-Ayland
2020-10-16 12:19 ` BALATON Zoltan via
2020-10-17 12:54 ` Mark Cave-Ayland
2020-10-17 15:56 ` BALATON Zoltan via
2020-10-18 16:01 ` Mark Cave-Ayland
2020-10-16 13:05 ` Philippe Mathieu-Daudé
2020-10-17 16:39 ` BALATON Zoltan via
2020-10-17 17:44 ` Philippe Mathieu-Daudé [this message]
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=6598b187-7936-563c-c06b-cb4315fa4cc1@amsat.org \
--to=f4bug@amsat.org \
--cc=balaton@eik.bme.hu \
--cc=mark.cave-ayland@ilande.co.uk \
--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).