From: BALATON Zoltan via <qemu-devel@nongnu.org>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: qemu-ppc@nongnu.org,
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
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 18:39:21 +0200 (CEST) [thread overview]
Message-ID: <edb86311-6093-9776-a81-17ee8205a6c@eik.bme.hu> (raw)
In-Reply-To: <7c34f053-268e-6dbf-205f-48792328ebe8@amsat.org>
[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]
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 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
next prev parent reply other threads:[~2020-10-17 16:40 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 [this message]
2020-10-17 17:44 ` Philippe Mathieu-Daudé
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=edb86311-6093-9776-a81-17ee8205a6c@eik.bme.hu \
--to=qemu-devel@nongnu.org \
--cc=balaton@eik.bme.hu \
--cc=f4bug@amsat.org \
--cc=mark.cave-ayland@ilande.co.uk \
--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).