On Tue, 19 Sept 2023 at 15:28, Tom Lendacky <thomas.lendacky@xxxxxxx> wrote: > > On 9/18/23 17:10, Kirill A . Shutemov wrote: > > 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 > > Yes, that fixes the issue for me. > Thanks for confirming. I've queued it up already, I will send it out later this week.
