--- Comment #17 from Marcel Moolenaar <mar...@freebsd.org> ---
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 loader
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 makes
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 anywhere
and this enables a few capabilities that other OSes already have and then some.
There are also downsides. You may need to support a large VA range if you want
to support pre-loading CD-ROM images or run entirely form a memory disk that'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 architectural
(x86-specific for now) problem and have a discussion on the arch@ mailing list.
We need a more people involved to bring this to a closure.
You are receiving this mail because:
You are the assignee for the bug.
email@example.com mailing list
To unsubscribe, send any mail to