svn commit: r287934 - head/sys/boot/efi/loader

[John Baldwin]

On Friday, October 09, 2015 07:59:06 PM Edward Tomasz Napierała wrote:
> On 0917T1630, John Baldwin wrote:
> > On Thursday, September 17, 2015 10:30:15 PM Bjoern A. Zeeb wrote:
> > > 
> > > > On 17 Sep 2015, at 20:43 , John Baldwin <jhb at freebsd.org> wrote:
> > > > 
> > > > 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
> > > >> 
> > > >> Log:
> > > >>  The EFI boot loader allocates a single chunk of contiguous memory to
> > > >>  hold the kernel, modules, and any other loaded data.  This memory block
> > > >>  is relocated to the kernel's expected location during the transfer of
> > > >>  control from the loader to the kernel.
> > > >> 
> > > >>  The GENERIC kernel on amd64 has recently grown such that a kernel + zfs.ko
> > > >>  no longer fits in the default staging size.  Bump the default size from
> > > >>  32MB to 48MB to provide more breathing room.
> > > > 
> > > > I believe that this should work fine for any system with 64MB of 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 area on
> > > > demand).
> > > 
> > > how do md_images work in that case?
> > 
> > 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 32MB so
> > that people who wished to deploy a large md_image can use a make flag to
> > build a loader with a larger staging size (I tested this with a 200+MB
> > mfsroot).
> 
> What would be required to get rid of that limitation altogether, ie make
> 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 option 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 relocatable
(and allow the module metadata to be anywhere and live in a chain instead
of an array) so that we can just load things wherever and leave them there
without having to relocate.

-- 
John Baldwin