qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: "Damien Hedde" <damien.hedde@greensocs.com>,
	"Alex Bennée" <alex.bennee@linaro.org>
Cc: Alistair Francis <alistair@alistair23.me>, qemu-devel@nongnu.org
Subject: Re: [PATCH] generic-loader: remove the ram_size limit when a loading binary file
Date: Thu, 7 Oct 2021 13:01:03 +0200	[thread overview]
Message-ID: <3b7a39e2-079f-0d01-2f51-612fcc823b8a@redhat.com> (raw)
In-Reply-To: <9b4ea846-5178-387f-cd0b-cd6e4ebcab7f@greensocs.com>

On 10/7/21 12:12, Damien Hedde wrote:
> 
> 
> On 10/7/21 09:54, Philippe Mathieu-Daudé wrote:
>> On 10/6/21 17:40, Alex Bennée wrote:
>>>
>>> Damien Hedde <damien.hedde@greensocs.com> writes:
>>>
>>>> On 10/6/21 13:49, Philippe Mathieu-Daudé wrote:
>>>>> On 10/6/21 13:37, Damien Hedde wrote:
>>>>>> Right now, we cannot load some binary file if it is bigger than the
>>>>>> machine's ram size. This limitation only occurs when loading a
>>>>>> binary file: we can load a corresponding elf file without this
>>>>>> limitation.
>>>>>>
>>>>>> This is an issue for machines that have small ram or do not use the
>>>>>> ram_size feature at all.
>>>>>>
>>>>>> Also get rid of "hw/boards.h" include, since we needed it only
>>>>>> to access `current_machine`.
>>>>>>
>>>>>> Fixes: e481a1f63c9 ("generic-loader: Add a generic loader")
>>>>>> Signed-off-by: Damien Hedde <damien.hedde@greensocs.com>
>>>>>> ---
>>>>>>
>>>>>> Hi Alistair,
>>>>>>
>>>>>> I found this while experimenting with a ram_size=0 machine.
>>>>
>>>>
>>>>
>>>>> Where are you loading your file?
>>>>>
>>>>
>>>> In a rom.
>>>>
>>>> The loader does not check at all that we are loading to the machine's
>>>> ram. It just check the size for the raw binary file format.
>>>
>>> It does beg the question of why you don't just construct your ROM file
>>> with the image in place there? Is this just a development convenience?
>>
>> generic-loader is designed from a CPU perspective, it uses the CPU AS
>> to load the image.
>>
>> If your image is in ROM, I'm not sure this is the correct API. I'd try
>> to do this without considering any CPU in the picture. The rom_add_*()
>> API might be more appropriate.
>>
>> My 2 cents anyway...
>>
> 
> I was looking for a user way of loading data in a memory-mapped area so
> I cannot use rom_add_*().
> I though the loader goal was to load something to any memory. But maybe
> I am mistaken.

I don't think you are mistaken, you likely found a design limitation
with this device, which isn't as generic as it aims to be.



  reply	other threads:[~2021-10-07 11:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-06 11:37 [PATCH] generic-loader: remove the ram_size limit when a loading binary file Damien Hedde
2021-10-06 11:49 ` Philippe Mathieu-Daudé
2021-10-06 11:58   ` Damien Hedde
2021-10-06 15:40     ` Alex Bennée
2021-10-07  7:54       ` Philippe Mathieu-Daudé
2021-10-07 10:12         ` Damien Hedde
2021-10-07 11:01           ` Philippe Mathieu-Daudé [this message]
2021-10-07  6:41     ` Alistair Francis
2021-10-07  7:59       ` Philippe Mathieu-Daudé
2021-10-08 10:38         ` Damien Hedde
2021-10-10 23:06           ` Alistair Francis
2021-10-07 10:12       ` Damien Hedde

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=3b7a39e2-079f-0d01-2f51-612fcc823b8a@redhat.com \
    --to=philmd@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=alistair@alistair23.me \
    --cc=damien.hedde@greensocs.com \
    --cc=qemu-devel@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).