* H. Peter Anvin <h...@zytor.com> wrote:
> On 11/9/18 5:40 AM, Li Zhijian wrote:
> > Just noticed that there is a field xloadflags at recent protocol
> > 60 Protocol 2.12: (Kernel 3.8) Added the xloadflags field and
> > extension fields
> > 61 to struct boot_params for loading bzImage and ramdisk
> > 62 above 4G in 64bit.
> > [snip]
> > 617 Field name: xloadflags
> > 618 Type: read
> > 619 Offset/size: 0x236/2
> > 620 Protocol: 2.12+
> > 621
> > 622 This field is a bitmask.
> > 623
> > 624 Bit 0 (read): XLF_KERNEL_64
> > 625 - If 1, this kernel has the legacy 64-bit entry point at
> > 0x200.
> > 626
> > 627 Bit 1 (read): XLF_CAN_BE_LOADED_ABOVE_4G
> > 628 - If 1, kernel/boot_params/cmdline/ramdisk can be above 4G.
> > 629
> >
> > maybe we can reuse this field and append a new Bit 5
> > XLF_INITRD_MAX_SIZE_4G and increase header version.
> > For the old protocol version 2.12+, if XLF_CAN_BE_LOADED_ABOVE_4G is
> > set, we can also realize ~4GB initrd is allowed.
> >
> > bootloader side:
> > if protocol >= 2.15
> > if XLF_INITRD_LOAD_BELOW_4G
> > support ~4G initrd
> > fi
> > else if protocol >=2.12
> > if XLF_CAN_BE_LOADED_ABOVE_4G
> > support ~4G initrd
> > fi
> > fi
> >
>
> The two are equivalent. Obviously you have to load above 4 GB if you
> have more than 4 GB of initrd. If XLF_CAN_BE_LOADED_ABOVE_4G is not
> set, then you most likely are on a 32-bit kernel and there are more
> fundamental limits (even if you were to load it above the 2 GB mark, you
> would be limited by the size of kernel memory.)
>
> So, in case you are wondering: the bootloader that broke when setting
> the initrd_max field above 2 GB was, of course, Grub.
>
> So just use XLF_CAN_BE_LOADED_ABOVE_4G. There is no need for a new flag
> or new field.
That's nice, and that's the best solution!
> Also note that the ext_ramdisk_image and ext_ramdisk_size are part of
> struct boot_params as opposed to struct setup_header, which means that
> they are not supported when entering via the 16-bit BIOS entry point,
> and I am willing to bet that there will be, ahem, "strangeness" if
> entered via the 32-bit entry point if at least the command line is
> loaded above the 4 GB mark; the initrd should be fine, though.
>
> This is obviosly not an issue in EFI environments, where we enter
> through the EFI handover entry point.
>
> The main reason these were not added to struct setup_header is that
> there are only 24 bytes left in that header and so space is highly
> precious. One way to deal with that if we really, really need to would
> be to add an initrd/initramfs type of setup_data.
Is there no way to extend that header by making an extended header part
of the payload?
IIRC that header is small and fixed size to be part of a single sector at
the very beginning of boot images, but accessing any extended header bits
from the payload section shouldn't really be an issue for a modern
bootloader to handle, right?
Such an extended header could use a more modern (self-extending) ABI as
well.
Thanks,
Ingo
