On Tue, Feb 20, 2024 at 01:18:29AM +0000, Ashish Kalra wrote: > From: Ashish Kalra <ashish.ka...@amd.com> > > During crashkernel boot only pre-allocated crash memory is presented as > E820_TYPE_RAM. This can cause PMD entry mapping unaccepted memory table > to be zapped during phys_pmd_init() as SNP/TDX guest use E820_TYPE_ACPI > to store the unaccepted memory table and pass it between the kernels on > kexec/kdump. > > E820_TYPE_ACPI covers not only ACPI data, but also EFI tables and might > be required by kernel to function properly. > > The problem was discovered during debugging kdump for SNP guest. The > unaccepted memory table stored with E820_TYPE_ACPI and passed between > the kernels on kdump was getting zapped as the PMD entry mapping this > is above the E820_TYPE_RAM range for the reserved crashkernel memory. > > Signed-off-by: Ashish Kalra <ashish.ka...@amd.com> > --- > arch/x86/mm/init_64.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c > index a0dffaca6d2b..207c6dddde0c 100644 > --- a/arch/x86/mm/init_64.c > +++ b/arch/x86/mm/init_64.c > @@ -524,7 +524,9 @@ phys_pmd_init(pmd_t *pmd_page, unsigned long paddr, > unsigned long paddr_end, > !e820__mapped_any(paddr & PMD_MASK, paddr_next, > E820_TYPE_RAM) && > !e820__mapped_any(paddr & PMD_MASK, paddr_next, > - E820_TYPE_RESERVED_KERN)) > + E820_TYPE_RESERVED_KERN) && > + !e820__mapped_any(paddr & PMD_MASK, paddr_next, > + E820_TYPE_ACPI)) > set_pmd_init(pmd, __pmd(0), init); > continue;
Why do you single out phys_pmd_init()? I think it has to be addressed for all page table levels as we do for E820_TYPE_RAM and E820_TYPE_RESERVED_KERN. -- Kiryl Shutsemau / Kirill A. Shutemov _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
