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

[Li Zhijian]

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

Thanks
Zhijian

> thanks
> -- PMM