| Message ID | 20180111113840.GF18820@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Akashi, On 11/01/18 11:38, AKASHI Takahiro wrote: > On Wed, Jan 10, 2018 at 11:26:55AM +0000, James Morse wrote: >> On 10/01/18 10:09, AKASHI Takahiro wrote: >>> This is a fix against the issue that crash dump kernel may hang up >>> during booting, which can happen on any ACPI-based system with "ACPI >>> Reclaim Memory." >>> (diagnosis) >>> * This fault is a data abort, alignment fault (ESR=0x96000021) >>> during reading out ACPI table. >>> * Initial ACPI tables are normally stored in system ram and marked as >>> "ACPI Reclaim memory" by the firmware. >>> * After the commit f56ab9a5b73c ("efi/arm: Don't mark ACPI reclaim >>> memory as MEMBLOCK_NOMAP"), those regions' attribute were changed >>> removing NOMAP bit and they are instead "memblock-reserved". >>> * When crash dump kernel boots up, it tries to accesses ACPI tables by >>> ioremap'ing them (through acpi_os_ioremap()). >>> * Since those regions are not included in device tree's >>> "usable-memory-range" and so not recognized as part of crash dump >>> kernel's system ram, ioremap() will create a non-cacheable mapping here. >> >> Ugh, because acpi_os_ioremap() looks at the efi memory map through the prism of >> what we pulled into memblock, which is different during kdump. >> >> Is an alternative to teach acpi_os_ioremap() to ask >> efi_mem_attributes() directly for the attributes to use? >> (e.g. arch_apei_get_mem_attribute()) > > I didn't think of this approach. > Do you mean a change like the patch below? Yes. Aha, you can pretty much re-use the helper directly. It was just a suggestion, removing the extra abstraction that is causing the bug could be cleaner ... > (I'm still debugging this code since the kernel fails to boot.) ... but might be too fragile. There are points during boot when the EFI memory map isn't mapped. I think that helper will return 'device memory' for everything when this happens. Thanks, James
===8<=== diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h index 32f465a80e4e..6953aaaf2bfa 100644 --- a/arch/arm64/include/asm/acpi.h +++ b/arch/arm64/include/asm/acpi.h @@ -16,6 +16,7 @@ #include <linux/psci.h> #include <asm/cputype.h> +#include <asm/io.h> #include <asm/smp_plat.h> #include <asm/tlbflush.h> @@ -29,18 +30,13 @@ /* Basic configuration for ACPI */ #ifdef CONFIG_ACPI +pgprot_t __acpi_get_mem_attribute(phys_addr_t addr); + /* ACPI table mapping after acpi_permanent_mmap is set */ static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) { - /* - * EFI's reserve_regions() call adds memory with the WB attribute - * to memblock via early_init_dt_add_memory_arch(). - */ - if (!memblock_is_memory(phys)) - return ioremap(phys, size); - - return ioremap_cache(phys, size); + return __ioremap(phys, size, __acpi_get_mem_attribute(phys)); } #define acpi_os_ioremap acpi_os_ioremap @@ -125,7 +121,10 @@ static inline const char *acpi_get_enable_method(int cpu) * for compatibility. */ #define acpi_disable_cmcff 1 -pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr); +static inline pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr) +{ + return __acpi_get_mem_attribute(addr); +} #endif /* CONFIG_ACPI_APEI */ #ifdef CONFIG_ACPI_NUMA diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c index b3162715ed78..43e9d8371f88 100644 --- a/arch/arm64/kernel/acpi.c +++ b/arch/arm64/kernel/acpi.c @@ -239,8 +239,7 @@ void __init acpi_boot_table_init(void) } } -#ifdef CONFIG_ACPI_APEI -pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr) +pgprot_t __acpi_get_mem_attribute(phys_addr_t addr) { /* * According to "Table 8 Map: EFI memory types to AArch64 memory @@ -261,4 +260,3 @@ pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr) return __pgprot(PROT_NORMAL_NC); return __pgprot(PROT_DEVICE_nGnRnE); } -#endif