grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: initrd loading, max size, addr_min, and page_align


From: Andrei Borzenkov
Subject: Re: initrd loading, max size, addr_min, and page_align
Date: Sun, 8 Feb 2015 20:02:30 +0300

В Thu, 5 Feb 2015 21:55:54 +0000
Eric Ewanco <address@hidden> пишет:

> 
> Background: I need to use a really large initrd for x86_64 (Linux 3.4.47), 
> and I'm near the limit, so I'm studying grub-core/loader/i386/linux.c to find 
> out the whys and wherefores of the GRUB 2.00 size limit.

GRUB 2.00 is way too old.

> 
> In the process of doing this I noticed a strange behavior.  The code has a 
> ceiling (addr_max) and a floor (addr_min) for the initrd.  The initrd is 
> loaded high, so that it ends at the ceiling and grows toward the floor as the 
> size of the initrd increases.  The odd behavior, or at least the one that I 
> don't understand, is that the floor grows upward toward the ceiling at the 
> same time.  The lines in question:
> 
>   addr_min = (grub_addr_t) prot_mode_target + prot_init_space
>              + page_align (size);
> 

This code is different in current GIT.

>   /* Put the initrd as high as possible, 4KiB aligned.  */
>   addr = (addr_max - size) & ~0xFFF;
> 
> page_align(size) returns a rounded-up alignment of size; i.e., if size is 
> 0x2335b728, it returns 0x2335c000.  Consequently, if the initrd size doubles, 
> the distance between the ceiling and the first byte doubles (expected), AND 
> the distance between the floor and the first byte halves because both are 
> proportional to the size.  I would expect the floor to remain relatively 
> constant based on the memory map.  Maybe be adjusted between 1-4k bytes for 
> alignment, but not by the whole size of the initrd.
> 
> I'm wondering if this is a bug, or if my modest and cursory understanding of 
> the code is incorrect.
> 
> If I am incorrect, can someone explain the page_align calculus, and also 
> explain how the value of GRUB_LINUX_INITRD_MAX_ADDRESS (0x37FFFFFF) was 
> determined, whether it is hard or might be revisable upward on some systems, 
> and what the implications are of changing it (i.e. will it either work or not 
> boot at all, or whether I might silently hose something).
> 
> Thanks,
> Eric Ewanco
> 
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]