> On Apr 11, 2021, at 6:14 PM, Baoquan He <b...@redhat.com> wrote:
>
> On 04/09/21 at 07:59pm, H. Peter Anvin wrote:
>> Why don't we do this unconditionally? At the very best we gain half a
>> megabyte of memory (except the trampoline, which has to live there, but it
>> is only a few kilobytes.)
>
> This is a great suggestion, thanks. I think we can fix it in this way to
> make code simpler. Then the specific caring of real mode in
> efi_free_boot_services() can be removed too.
>
This whole situation makes me think that the code is buggy before and buggy
after.
The issue here (I think) is that various pieces of code want to reserve
specific pieces of otherwise-available low memory for their own nefarious uses.
I don’t know *why* crash kernel needs this, but that doesn’t matter too much.
I propose that the right solution is to give low-memory-reserving code paths
two chances to do what they need: once at the very beginning and once after EFI
boot services are freed.
Alternatively, just reserve *all* otherwise unused sub 1M memory up front, then
release it right after releasing boot services, and then invoke the special
cases exactly once.
In either case, the result is that the crashkernel mess gets unified with the
trampoline mess. One way the result is called twice and needs to be more
careful, and the other way it’s called only once.
Just skipping freeing boot services seems wrong. It doesn’t unmap boot
services, and skipping that is incorrect, I think. And it seems to result in a
bogus memory map in which the system thinks that some crashkernel memory is EFI
memory instead.
Let’s please just fix the problem instead of papering over it with more hacks.
> Thanks
> Baoquan
>
