summaryrefslogtreecommitdiffstats
path: root/fs/efivarfs
diff options
context:
space:
mode:
authorArd Biesheuvel <ardb@kernel.org>2023-08-16 21:05:57 +0200
committerArd Biesheuvel <ardb@kernel.org>2023-09-11 06:37:51 +0000
commite7761d827e99919c32400056a884e481ef008ec4 (patch)
treeb7a092fe720720689d5a695eb325b131755f74b4 /fs/efivarfs
parentaba7e066c738d4b349413a271b2a236aa55bacbc (diff)
downloadlinux-e7761d827e99919c32400056a884e481ef008ec4.tar.gz
linux-e7761d827e99919c32400056a884e481ef008ec4.tar.bz2
linux-e7761d827e99919c32400056a884e481ef008ec4.zip
efi/unaccepted: Use ACPI reclaim memory for unaccepted memory table
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. Fixes: 745e3ed85f71 ("efi/libstub: Implement support for unaccepted memory") Reported-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Diffstat (limited to 'fs/efivarfs')
0 files changed, 0 insertions, 0 deletions