From owner-svn-src-head@freebsd.org Mon Oct 19 21:30:37 2015 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE7E7A19ACD; Mon, 19 Oct 2015 21:30:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 89CD81950; Mon, 19 Oct 2015 21:30:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9F3F6B949; Mon, 19 Oct 2015 17:30:36 -0400 (EDT) From: John Baldwin To: Edward Tomasz =?utf-8?B?TmFwaWVyYcWCYQ==?= Cc: "Bjoern A. Zeeb" , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r287934 - head/sys/boot/efi/loader Date: Mon, 19 Oct 2015 11:25:49 -0700 Message-ID: <7461243.7D4jZgdzzK@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20151009175906.GA4501@brick.home> References: <201509172036.t8HKalKU088025@repo.freebsd.org> <1581085.vcsbvoROWY@ralph.baldwin.cx> <20151009175906.GA4501@brick.home> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 19 Oct 2015 17:30:36 -0400 (EDT) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 21:30:37 -0000 On Friday, October 09, 2015 07:59:06 PM Edward Tomasz Napiera=C5=82a wr= ote: > On 0917T1630, John Baldwin wrote: > > On Thursday, September 17, 2015 10:30:15 PM Bjoern A. Zeeb wrote: > > >=20 > > > > On 17 Sep 2015, at 20:43 , John Baldwin wrote= : > > > >=20 > > > > On Thursday, September 17, 2015 08:36:47 PM John Baldwin wrote:= > > > >> Author: jhb > > > >> Date: Thu Sep 17 20:36:46 2015 > > > >> New Revision: 287934 > > > >> URL: https://svnweb.freebsd.org/changeset/base/287934 > > > >>=20 > > > >> Log: > > > >> The EFI boot loader allocates a single chunk of contiguous me= mory to > > > >> hold the kernel, modules, and any other loaded data. This me= mory block > > > >> is relocated to the kernel's expected location during the tra= nsfer of > > > >> control from the loader to the kernel. > > > >>=20 > > > >> The GENERIC kernel on amd64 has recently grown such that a ke= rnel + zfs.ko > > > >> no longer fits in the default staging size. Bump the default= size from > > > >> 32MB to 48MB to provide more breathing room. > > > >=20 > > > > I believe that this should work fine for any system with 64MB o= f RAM. One > > > > downside of the static size is that the loader fails if it can'= t allocate > > > > a contiguous staging size (it isn't able to grow the staging ar= ea on > > > > demand). > > >=20 > > > how do md_images work in that case? > >=20 > > The md_image has to fit into the same staging area (kernel plus any= other > > files loaded by the loader including modules and md_images all have= to fit > > in the staging area). That was the original motivation for making = the > > staging area a build-time tunable rather than always hardcoded at 3= 2MB so > > that people who wished to deploy a large md_image can use a make fl= ag to > > build a loader with a larger staging size (I tested this with a 200= +MB > > mfsroot). >=20 > What would be required to get rid of that limitation altogether, ie m= ake > it dynamic? Right now it's quite a regression compared to the usual > (non-UEFI) loader. >From earlier in the thread: It's a harder problem to solve. Feel free to submit patches. One opti= on is to let the staging code allocate more memory chunks from EFI and chain = them together. However, your relocate code will now have to be smart enough= to order the various copies in such a way that none of them copy over top = of each other. I haven't sat down to see if that's easy to solve or not. The other approach I suggested earlier is to make the kernel relocatabl= e (and allow the module metadata to be anywhere and live in a chain inste= ad of an array) so that we can just load things wherever and leave them th= ere without having to relocate. --=20 John Baldwin