On Tue, 19 Sept 2023 at 13:37, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > 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. Tom, Could you confirm whether or not this is related to loading a crashkernel?
