Breno Leitao <leitao@xxxxxxxxxx> writes: > 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? Just specific cases. There could be other linux specific reasons to tell the memblock allocator not to allocation from a specific range of memory. Eric
