Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Aug 2017 18:01:25 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 221813] Mechanism is needed to utilize discontinuous memory segments supplied by the EFI and other boot envs
Message-ID:  <bug-221813-8@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221813

            Bug ID: 221813
           Summary: Mechanism is needed to utilize discontinuous memory
                    segments supplied by the EFI and other boot envs
           Product: Base System
           Version: CURRENT
          Hardware: Any
               URL: http://bit.ly/2vdC30w
                OS: Any
            Status: New
          Keywords: uefi
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs@FreeBSD.org
          Reporter: sobomax@FreeBSD.org
                CC: freebsd-arch@FreeBSD.org, marcel@FreeBSD.org

This is a follow-up ticket created after good discussion along the lines of=
 bug
#211746, particularly good comment that sums up the essence of it is quoted
below.

In our particular case this causes to inability to use more than 64MB or me=
mory
to load kernel and images. The solution could also be some kind of
scatter-gather mechanism for blobs or memory, so if the blob is to big to f=
it
into single chunk then loader splits it over multiple regions and lets kern=
el
do its VM magic to stitch pages back together in the KVA. This will leave us
with 64MB of data for the kernel, but at least we would be able to pre-load
much larger images.

--------------------------------
Marcel Moolenaar  freebsd_committer 2017-02-17 18:34:37 UTC
I think the complexity of having the kernel at any other physical address is
what has us do the staging/copying. It was a quick-n-dirty mechanism that
avoided a lot of work and complexity -- which is ok if you don't know it's
worth/needed to go through all that hassle. And I guess it looks like we now
hit a case that warrants us to start looking at a real solution.

As an example (for inspiration):
For Itanium I had the kernel link against a fixed virtual address. The load=
er
built the VA-to-PA mapping based on where EFI allocated blobs of memory. The
mapping was loaded/activated prior to booting the kernel and the loader gave
the kernel all the information it needed to work with the mapping. This mak=
es
it possible to allocate memory before the VM system is up and running.
Ultimately the mapping needs to be incorporated into the VM system and this=
 is
where different CPU architectures have different challenges and solutions.

Note that there are advantages to having the kernel link against a virtual
address. In general it makes it easier to load or relocate the kernel anywh=
ere
and this enables a few capabilities that other OSes already have and then s=
ome.

There are also downsides. You may need to support a large VA range if you w=
ant
to support pre-loading CD-ROM images or run entirely form a memory disk tha=
t's
preloaded. A few GB of address space would be good to have.

Anyway: It's probably time that to you restate this bug into an architectur=
al
(x86-specific for now) problem and have a discussion on the arch@ mailing l=
ist.

We need a more people involved to bring this to a closure.
Good luck
--------------------------------

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-221813-8>