On Fri, 18 Aug 2023 at 17:16, Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> wrote: > > 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. > Yeah, you're right. So this patch is necessary in any case. Do we also need the EFI side patch then?
