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 <al...@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
