From: Ingo Molnar <mingo@kernel.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Li Zhijian <zhijianx.li@intel.com>,
Juergen Gross <jgross@suse.com>,
Li Zhijian <lizhijian@cn.fujitsu.com>,
Peter Maydell <peter.maydell@linaro.org>,
x86@kernel.org, bp@alien8.de, mingo@redhat.com,
tglx@linutronix.de, QEMU Developers <qemu-devel@nongnu.org>,
Philip Li <philip.li@intel.com>,
linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Kees Cook <keescook@chromium.org>
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 [thread overview]
Message-ID: <20181112045624.GA28219@gmail.com> (raw)
In-Reply-To: <d9c293bd-b43f-999c-55f1-3b90a6020065@zytor.com>
* H. Peter Anvin <hpa@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
next prev parent reply other threads:[~2018-11-12 4:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1541674784-25936-1-git-send-email-lizhijian@cn.fujitsu.com>
[not found] ` <1541674784-25936-2-git-send-email-lizhijian@cn.fujitsu.com>
[not found] ` <CAFEAcA_47wyar3WNhuBmNPdr02RHx-wn_TeyFaajpjzvzG8j5Q@mail.gmail.com>
2018-11-09 1:47 ` [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 7:20 ` Ingo Molnar
2018-11-09 9:57 ` Li Zhijian
2018-11-09 10:04 ` Juergen Gross
2018-11-09 13:11 ` Li Zhijian
2018-11-09 13:40 ` Li Zhijian
2018-11-09 21:10 ` H. Peter Anvin
2018-11-12 4:56 ` Ingo Molnar [this message]
2018-11-12 6:00 ` H. Peter Anvin
2018-11-12 6:19 ` Ingo Molnar
2018-11-12 6:36 ` H. Peter Anvin
2018-11-12 16:47 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181112045624.GA28219@gmail.com \
--to=mingo@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizhijian@cn.fujitsu.com \
--cc=mingo@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philip.li@intel.com \
--cc=qemu-devel@nongnu.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
--cc=zhijianx.li@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).