On Thu, Aug 17, 2023 at 10:25:56PM +0200, Ard Biesheuvel wrote: > On Wed, 16 Aug 2023 at 23:24, Kirill A. Shutemov > <kirill.shutemov@xxxxxxxxxxxxxxx> wrote: > > > > e820__end_of_ram_pfn() is used to calculate max_pfn which, among other > > things, guides where direct mapping ends. Any memory above max_pfn is > > not going to be present in the direct mapping. > > > > e820__end_of_ram_pfn() finds the end of the ram based on the highest > > E820_TYPE_RAM range. But it doesn't includes E820_TYPE_ACPI ranges into > > calculation. > > > > Despite the name, E820_TYPE_ACPI covers not only ACPI data, but also EFI > > tables and might be required by kernel to function properly. > > > > Usually the problem is hidden because there is some E820_TYPE_RAM memory > > above E820_TYPE_ACPI. But crashkernel only presents pre-allocated crash > > memory as E820_TYPE_RAM on boot. If the preallocated range is small, it > > can fit under the last E820_TYPE_ACPI range. > > > > Modify e820__end_of_ram_pfn() and e820__end_of_low_ram_pfn() to cover > > E820_TYPE_ACPI memory. > > > > The problem was discovered during debugging kexec for TDX guest. TDX > > guest uses E820_TYPE_ACPI to store the unaccepted memory bitmap and pass > > it between the kernels on kexec. > > > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> > > No objections to this, but we might also simply drop E820_TYPE_ACPI > altogether: it is only used for EFI_ACPI_RECLAIM_MEMORY, which is > memory that can be used by the OS as ordinary RAM if it is not > interested in the contents (or has already consumed them). So this > could arguably be classified as E820_TYPE_RAM too. Hm. I'm not sure about this. E820_TYPE_ACPI also get tracked as IORES_DESC_ACPI_TABLES resource and get passed to the next kernel on kexec, regardless if it is crash kernel or not. I'm not sure we would not break anything. -- Kiryl Shutsemau / Kirill A. Shutemov
