From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1YKVFo-0001iu-Hg for mharc-grub-devel@gnu.org; Sun, 08 Feb 2015 12:02:40 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41533) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKVFm-0001ia-6L for grub-devel@gnu.org; Sun, 08 Feb 2015 12:02:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YKVFh-0005hs-QW for grub-devel@gnu.org; Sun, 08 Feb 2015 12:02:38 -0500 Received: from mail-lb0-x234.google.com ([2a00:1450:4010:c04::234]:63193) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKVFh-0005hb-Iv for grub-devel@gnu.org; Sun, 08 Feb 2015 12:02:33 -0500 Received: by mail-lb0-f180.google.com with SMTP id z12so4760720lbi.11 for ; Sun, 08 Feb 2015 09:02:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=b1QLKmYkuE2zLkW3cqfA8qLUWCAgDoO3MzHPumAAbmQ=; b=o/lLjyY9cDXZFZKhsOlJypSddCyzlqZhlfjQQHL4Q2ObWLqUFPKUdxA7nLxtVkXHen 5F72RFTcT7EfxD3ZmoenvWlOC7v+b1UKxBTPyPeG4KbiGy5M4gnOI+VVnlh4sEsA0Yss XbRqMaiTIthScMyD4XjkUeTVHK0mmdpCsdEXM3QZjZbLmXWacVzAyg4g0jv01MnXyxWn tkUiys/FldGNfUL13AzQ2iiUAnPm41HbZXXzIvNdBj/G+rOWFybHDnaZCq9gqIo3DayS Ffm9sVs/Vx7OxxqBhydbcaNISTad5V+X5khKs4+UA7pTMVaEa+duNshxlK62EHxRW40T BRJg== X-Received: by 10.112.92.129 with SMTP id cm1mr10011260lbb.85.1423414952424; Sun, 08 Feb 2015 09:02:32 -0800 (PST) Received: from opensuse.site (ppp91-76-14-38.pppoe.mtu-net.ru. [91.76.14.38]) by mx.google.com with ESMTPSA id ug11sm1590821lac.47.2015.02.08.09.02.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Feb 2015 09:02:31 -0800 (PST) Date: Sun, 8 Feb 2015 20:02:30 +0300 From: Andrei Borzenkov To: Eric Ewanco Subject: Re: initrd loading, max size, addr_min, and page_align Message-ID: <20150208200230.53f274fe@opensuse.site> In-Reply-To: <66CA070CE60D374FB9F56957F4E00BBA14E22944@gbplmail01.genband.com> References: <66CA070CE60D374FB9F56957F4E00BBA14E22944@gbplmail01.genband.com> X-Mailer: Claws Mail 3.11.0 (GTK+ 2.24.25; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::234 Cc: "grub-devel@gnu.org" X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 17:02:39 -0000 =D0=92 Thu, 5 Feb 2015 21:55:54 +0000 Eric Ewanco =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >=20 > 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. >=20 > 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 t= he size of the initrd increases. The odd behavior, or at least the one tha= t I don't understand, is that the floor grows upward toward the ceiling at = the same time. The lines in question: >=20 > addr_min =3D (grub_addr_t) prot_mode_target + prot_init_space > + page_align (size); >=20 This code is different in current GIT. > /* Put the initrd as high as possible, 4KiB aligned. */ > addr =3D (addr_max - size) & ~0xFFF; >=20 > page_align(size) returns a rounded-up alignment of size; i.e., if size is= 0x2335b728, it returns 0x2335c000. Consequently, if the initrd size doubl= es, 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 relativel= y constant based on the memory map. Maybe be adjusted between 1-4k bytes f= or alignment, but not by the whole size of the initrd. >=20 > I'm wondering if this is a bug, or if my modest and cursory understanding= of the code is incorrect. >=20 > 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 det= ermined, whether it is hard or might be revisable upward on some systems, a= nd what the implications are of changing it (i.e. will it either work or no= t boot at all, or whether I might silently hose something). >=20 > Thanks, > Eric Ewanco >=20 >=20 >=20