Hello Eric, On Tue, Sep 10, 2024 at 09:26:00AM -0500, Eric W. Biederman wrote: > > I am wondering if that memory region/range should be part of e820 table that is > > passed by EFI firmware to kernel, and if it is not passed (as it is not being > > passed today), then the kernel doesn't need to respect it, and it is free to > > overwrite (as it does today). In other words, this is a firmware bug and not a > > kernel bug. > > > > Am I missing something? > > I agree that this appears to be a firmware bug. This memory is reserved > in one location and not in another location. That was is our current understanding also, but, having the same issue in EDK2 and on a real machine firmware was surprising. Anyway, I've CCed the EDK2 mailing list in this thread as well, let's see if someone has any comment. > As I recall the memblock allocator is the bootstrap memory allocator > used when bringing up the kernel. So I don't see reserving something > in the memblock allocator as being authoritative as to how the firmware > has setup memory. > > I would suggest writing a patch to update whatever is calling > memblock_reserve to also, or perhaps in preference to update the e820 > map. If the code is not x86 specific I would suggest using ACPI's > arch_reserve_mem_area call. Should all memblock_reserve() memory ranges be mapped to e820 table, or, just specific cases where we see problems? Thanks
