More than 1G of loader-visible RAM?

[Konstantin Belousov]

On Sun, Jul 12, 2020 at 12:32:08AM +0300, Lytochkin Boris wrote:
> Hi.
> 
> I am trying to make a patch that gives loader ability to bring whole
> partitions as preload md(4) items. While this could sound a bit crazy, it
> allows making an easy to get "diskless" routers: root partition is 2Gb
> stored on HDD and I have 4Gb of RAM loader can get root partition into
> memory and kernel will use it as a root partition. Once OS is up and
> running, HDD can be set to sleep mode (via /etc/rc.local or similar)
> 
> Currently I do the same thing via init_script that detects boot partition,
> run mdconfig and dd. Delegating this job to loader will make this setup
> much more straightforward.
> 
> Currently my patch for loader can copy partitions up to ~1G and it seems
> this is a limitation in stand/i386/libi386/elf64_freebsd.c:
> ====
>     /*
>      * This is kinda brutal, but every single 1GB VM memory segment points
> to
>      * the same first 1GB of physical memory.  But it is more than adequate.
>      */
>     for (i = 0; i < 512; i++) {
> ...
> ====
> Comment comes from 2003 which was quite adequate back then. I am not that
> fluent in real memory programming thus I write this email seeking a hint if
> this 1Gb RAM limitation can be altered allowing more memory to be used by
> loader that will be functional.
Current setup requires 3 page table pages that are statically allocated
in the loader data segment.  Mapping each additional 1G would require one
more page.  This is doable but is not too friendly to limited space we
have for loaders text + data, I think they are still have to live in low
640K for non-EFI boot.

IMO what is wrong there is a protocol that requires mdroot to be fully
mapped, I think it is only due to the way loader is coded right now.
Kernel does not need anything from mdroot until pmap is fully initialized,
so it really does not care much about this mapping.