[Top][All Lists]

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

initrd loading, max size, addr_min, and page_align

From: Eric Ewanco
Subject: initrd loading, max size, addr_min, and page_align
Date: Thu, 5 Feb 2015 21:55:54 +0000


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.


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);


  /* 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).



Eric Ewanco


Attachment: Eric J Ewanco.vcf
Description: Eric J Ewanco.vcf

reply via email to

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