[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to a
From: |
Ingo Molnar |
Subject: |
Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd |
Date: |
Mon, 12 Nov 2018 05:56:24 +0100 |
User-agent: |
Mutt/1.9.4 (2018-02-28) |
* H. Peter Anvin <address@hidden> 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
- Re: [Qemu-devel] [RFC/PoC PATCH 2/3] change size type from int to int64_t on load_image(), (continued)
Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd, Peter Maydell, 2018/11/08
- Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd, Li Zhijian, 2018/11/08
- Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd, Ingo Molnar, 2018/11/09
- Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd, Li Zhijian, 2018/11/09
- Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd, Juergen Gross, 2018/11/09
- Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd, Li Zhijian, 2018/11/09
- Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd, Li Zhijian, 2018/11/09
- Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd, H. Peter Anvin, 2018/11/09
- Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd,
Ingo Molnar <=
- Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd, H. Peter Anvin, 2018/11/12
- Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd, Ingo Molnar, 2018/11/12
- Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd, H. Peter Anvin, 2018/11/12
- Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd, H. Peter Anvin, 2018/11/12
Re: [Qemu-devel] [RFC/PoC PATCH 0/3] support initrd size up to 4G, Wainer dos Santos Moschetta, 2018/11/08