Web lists-archives.com

Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd

On 11/08/2018 07:06 PM, Peter Maydell wrote:
On 8 November 2018 at 10:59, Li Zhijian <lizhijian@xxxxxxxxxxxxxx> wrote:
x86/x86_64 has alredy supported 4G initrd.

  # (Header version 0x0203 or later) the highest safe address for the contents
  # of an initrd. The current kernel allows up to 4 GB, but leave it at 2 GB to
  # avoid possible bootloader bugs.

CC: Philip Li <philip.li@xxxxxxxxx>
Signed-off-by: Li Zhijian <lizhijian@xxxxxxxxxxxxxx>
  hw/i386/pc.c | 6 ++++++
  1 file changed, 6 insertions(+)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index cd5029c..e1b910f 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -913,6 +913,12 @@ static void load_linux(PCMachineState *pcms,
      /* highest address for loading the initrd */
      if (protocol >= 0x203) {
          initrd_max = ldl_p(header+0x22c);
+        if (initrd_max == 0x7fffffff) {
+            /* for some reasons, initrd_max is hard code with 0x7fffffff
+             * hard code to 4G - 1 to allow 4G initrd
+             */
+            initrd_max = UINT32_MAX - 1;
+        }
I don't understand this. If the header of the file we're using
says "this is the maximum", then we should trust the header to
in fact not be lying to us, shouldn't we ?

If the kernel initrd creation process creates an initrd which
is larger than 2GB and also claims that it can't be placed
with any part of it above 2GB, then that sounds like a bug
in the initrd creation process...

Exactly, it's a real problem.

Add x86 maintainers and LKML:

The background is that QEMU want to support up to 4G initrd. but linux header (
initrd_addr_max field) only allow 2G-1.
Is one of the below approaches reasonable:
1) change initrd_addr_max to 4G-1 directly simply(arch/x86/boot/header.S)?
2) lie QEMU bootloader the initrd_addr_max is 4G-1 even though header said 2G-1
3) any else

      } else {
          initrd_max = 0x37ffffff;
This patch should come last in the series: only after we have fixed all
of QEMU's internal plumbing to handle larger initrd sizes should we
enable it.

Got it.


-- PMM