Re: [Qemu-devel] [PATCH 1/5] elf-loader: Allow late loading of elf

[Thomas Huth <thuth@redhat.com>]

On 24.02.2017 12:09, Christian Borntraeger wrote:
> On 02/24/2017 11:44 AM, Thomas Huth wrote:
>> On 21.02.2017 11:23, Christian Borntraeger wrote:
>>> On 02/20/2017 04:33 PM, Thomas Huth wrote:
>>>> On 20.02.2017 15:19, Cornelia Huck wrote:
>>>>> From: Farhan Ali <alifm@linux.vnet.ibm.com>
>>>>>
>>>>> The current QEMU ROM infrastructure rejects late loading of ROMs.
>>>>> And ELFs are currently loaded as ROM, this prevents delayed loading
>>>>> of ELFs. So when loading ELF, allow the user to specify if ELF should
>>>>> be loaded as ROM or not.
>>>>>
>>>>> If an ELF is not loaded as ROM, then they are not restored on a
>>>>> guest reboot/reset and so its upto the user to handle the reloading.
>>>>
>>>> Could you maybe also explain here why you need such a delayed ELF
>>>> loading? Why can't you load the s390-netboot.img at the same time as
>>>> s390-ccw.img?
>>>
>>> Please read the cover letter for some details how to build such a netrom.
>>
>> Sure, understood, but I still did not see an explanation why this can't
>> be loaded as "ROM", too / why it needs to be loaded "delayed"? Does the
>> image data need to be writable in memory? Or is the information not
>> available yet at that point in time, whether the user wants to do a
>> network boot or not? Don't get me wrong, I'm basically fine with this
>> patch, I'm just missing some explanation *why* you have to do it this way.
> 
> As I already wrote, the rom will be big. kernel + ramdisk will take easily
> 10-30Mbytes. This is loaded twice (in the rom as data and into the guest)
> So this will waste lets say 60Mbyte per guest for nothing.

OK, now that's a proper explanation, thanks! ... it would maybe be
helpful for future reviewers to include such a proper statement in the
patch description (or cover letter), too.

 Thomas