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

[Peter Maydell]

On 8 November 2018 at 10:59, Li Zhijian <address@hidden> wrote:
> x86/x86_64 has alredy supported 4G initrd.
>
> linux/arch/x86/boot/header.S:
>  # (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 <address@hidden>
> Signed-off-by: Li Zhijian <address@hidden>
> ---
>  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...

>      } 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.

thanks
-- PMM