On Mon, Sep 18, 2023 at 05:03:59PM -0500, Tom Lendacky wrote: > On 8/16/23 14:05, Ard Biesheuvel wrote: > > Kyril reports that crashkernels fail to work on confidential VMs that > > rely on the unaccepted memory table, and this appears to be caused by > > the fact that it is not considered part of the set of firmware tables > > that the crashkernel needs to map. > > > > This is an oversight, and a result of the use of the EFI_LOADER_DATA > > memory type for this table. The correct memory type to use for any > > firmware table is EFI_ACPI_RECLAIM_MEMORY (including ones created by the > > EFI stub), even though the name suggests that is it specific to ACPI. > > ACPI reclaim means that the memory is used by the firmware to expose > > information to the operating system, but that the memory region has no > > special significance to the firmware itself, and the OS is free to > > reclaim the memory and use it as ordinary memory if it is not interested > > in the contents, or if it has already consumed them. In Linux, this > > memory is never reclaimed, but it is always covered by the kernel direct > > map and generally made accessible as ordinary memory. > > > > On x86, ACPI reclaim memory is translated into E820_ACPI, which the > > kexec logic already recognizes as memory that the crashkernel may need > > to to access, and so it will be mapped and accessible to the booting > > crash kernel. > > > > Reported-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> > > Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx> > > --- > > drivers/firmware/efi/libstub/unaccepted_memory.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/firmware/efi/libstub/unaccepted_memory.c b/drivers/firmware/efi/libstub/unaccepted_memory.c > > index ca61f4733ea58693..9a655f30ba47db01 100644 > > --- a/drivers/firmware/efi/libstub/unaccepted_memory.c > > +++ b/drivers/firmware/efi/libstub/unaccepted_memory.c > > @@ -62,7 +62,7 @@ efi_status_t allocate_unaccepted_bitmap(__u32 nr_desc, > > bitmap_size = DIV_ROUND_UP(unaccepted_end - unaccepted_start, > > EFI_UNACCEPTED_UNIT_SIZE * BITS_PER_BYTE); > > - status = efi_bs_call(allocate_pool, EFI_LOADER_DATA, > > + status = efi_bs_call(allocate_pool, EFI_ACPI_RECLAIM_MEMORY, > > I bisected an SNP guest crash when using the tip tree to this commit. When > the kernel switches over to the swapper_pg_dir in init_mem_mapping(), the > unaccepted table is no longer mapped. Here's a copy of the stack trace: Could you try this patch: https://lore.kernel.org/all/20230917170629.d35gnwb6o54bdrhl@xxxxxxxxxxxxxxxxx -- Kiryl Shutsemau / Kirill A. Shutemov
