On Tue, Jan 15, 2019 at 09:35:09AM +0800, Li Zhijian wrote:
> Hi Eduardo
>
>
> On 1/15/19 01:53, Eduardo Habkost wrote:
>
> + if (protocol >= 0x20c &&
> + lduw_p(header+0x236) & XLF_CAN_BE_LOADED_ABOVE_4G) {
> + /*
> + * Linux has supported initrd up to 4 GB for a very long
> time (2007,
> + * long before XLF_CAN_BE_LOADED_ABOVE_4G which was added in
> 2013),
> + * though it only sets initrd_max to 2 GB to "work around
> bootloader
> + * bugs". Luckily, QEMU firmware(which does something like
> bootloader)
> + * has supported this.
> + *
> + * It's believed that if XLF_CAN_BE_LOADED_ABOVE_4G is set,
> initrd can
> + * be loaded into any address.
> + *
> + * In addition, initrd_max is uint32_t simply because QEMU
> doesn't
> + * support the 64-bit boot protocol (specifically the
> ext_ramdisk_image
> + * field).
> + *
> + * Therefore here just limit initrd_max to UINT32_MAX simply
> as well.
> + *
> + * FIXME: it's possible that linux protocol within [0x208,
> 0x20c]
> + * supports up to 4G initrd as well.
>
> I don't understand what exactly this FIXME comment is
> documenting. What exactly needs to be fixed?
>
>
> XLF_CAN_BE_LOADED_ABOVE_4G is one of the indicators, actually as comments
> said,
> linux has supported up to 4 GB initrd since linux-2.26(protocol version
> 0x208).
>
>
> I just want to comment that linux with protocol within [0x208, 0x20c]
> supports up to 4 GB initrd as well.
>
> Is documenting with FIXME appropriate?
>
>
> Thanks
>
>
Fixme should say what is missing in the qemu implementation.
E.g.
/*
* Bar 2010 and up can actually be supported using foo.
* FIXME: make use of foo to support bar.
*/
--
MST
