From patchwork Thu Jan 11 11:38:41 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 10157923 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id D2612602B3 for ; Thu, 11 Jan 2018 11:40:04 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id ADB3D286C5 for ; Thu, 11 Jan 2018 11:40:04 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A280A2874A; Thu, 11 Jan 2018 11:40:04 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 89916286C5 for ; Thu, 11 Jan 2018 11:40:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bNNXYLprq3Y61LlAwCjmfnXfE/y0yU5FTaeiw1CNGvI=; b=Zp+rPeB7wU1Fcj YLjK+8209JO5aP2lKzT+sjaHHWf4MB2ylai4oBOYa+86rdJDkikDBGGeOIyhyzshfPdlWt5rsUThH MoS40oU7x4/QxCEzGhzCJL0h74UlQ9+8mA/rPmPupc3/2L42fYtjTOHPTymlAF1YIXRVKcGD0674O CUAVt+VHXoG6wgLTjXbBBblfD50SdZoIHM/Oc0RfFF+2sCSoK6bmrNmX13WI+nyWhGviKdOGGpmak v1FKMAmEAleybzcPU1WpIyXG9gzf8ArD3bW5vPocAlpfz8ET7h2FO2N3D98icHbNxINoNZYB4TXmf NNZp3Th9uckZrjVWMQ8Q==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.89 #1 (Red Hat Linux)) id 1eZbDF-0007o7-7t; Thu, 11 Jan 2018 11:40:01 +0000 Received: from mail-it0-x243.google.com ([2607:f8b0:4001:c0b::243]) by bombadil.infradead.org with esmtps (Exim 4.89 #1 (Red Hat Linux)) id 1eZbDA-0007kq-6Z for linux-arm-kernel@lists.infradead.org; Thu, 11 Jan 2018 11:39:57 +0000 Received: by mail-it0-x243.google.com with SMTP id p124so3609241ite.1 for ; Thu, 11 Jan 2018 03:39:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=hXC/I7g++fEeVyEtnZzRAlAnOGR1exB6cr7MPdjXX28=; b=SKo5chV3GQfhFTcKKl65W+9uXDb+vl/MMVe/ASGZD9sJIZDrHgRmZcZU1g1RC+5TCO pLdzPlv5QZ1ud6NfCSQrEv/4c21EGRe33VVJFtMjJfBTFPcrgNgkKswkZHc4kN3fF5t2 +un7R2ogyoX2ACqTaXWFBYX08BGNMDC5tofF4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=hXC/I7g++fEeVyEtnZzRAlAnOGR1exB6cr7MPdjXX28=; b=uAnQSosjHzNP5dSfxP16VI2ruG9ipHW05BFGm3QNg9U88CVbhe4lkqUooIjPrurTPi h9Cr/eX1Mj1zoIH0XWQngA8dWOCUqHEzSWSAKWA4qg7Deyg/2SvXr7e7ojiI+R/YnEpq l+dlpWneLLLDzUshaZHy07Pkupyh5pC3PZJtgiTyvSpxQUev5DBTTao3BqYWR+EY4dg0 /EdQiUiUXI7Y+RnZvXApTz9OAkTig1qEw7b15L+jnYqqcaxA4k7YWAhVvDP/bMfeDLx9 CgMQtcsXpTIDGv1pUhWyPxPQhMv0uJXjeU52lCx0yMf7ivWViPsfddHUdEmjBCtyUPfu anAQ== X-Gm-Message-State: AKwxytdleuWVQ6zx/5byzgv4VUBi22P6d0BL6AtyyRMWg0d3Su0866bX WnIok5YICOTOyB1OfOZdBiC82A== X-Google-Smtp-Source: ACJfBotm5URDw4Y4IEDmGrFFONGAKv3TRGzJ/KgAM9EXUS0osiyzEMW4FP+2k7TZuyBxkaLxnB18Kw== X-Received: by 10.36.25.140 with SMTP id b134mr827017itb.21.1515670784987; Thu, 11 Jan 2018 03:39:44 -0800 (PST) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id j81sm11413135ioi.9.2018.01.11.03.39.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jan 2018 03:39:44 -0800 (PST) Date: Thu, 11 Jan 2018 20:38:41 +0900 From: AKASHI Takahiro To: James Morse Subject: Re: [PATCH] arm64: kdump: retain reserved memory regions Message-ID: <20180111113840.GF18820@linaro.org> Mail-Followup-To: AKASHI Takahiro , James Morse , catalin.marinas@arm.com, will.deacon@arm.com, ard.biesheuvel@linaro.org, bhsharma@redhat.com, kexec@lists.infradead.org, dyoung@redhat.com, linux-arm-kernel@lists.infradead.org References: <20180110100943.6082-1-takahiro.akashi@linaro.org> <5A55F87F.2080501@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5A55F87F.2080501@arm.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180111_033956_256777_5C8F8006 X-CRM114-Status: GOOD ( 24.80 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ard.biesheuvel@linaro.org, catalin.marinas@arm.com, bhsharma@redhat.com, will.deacon@arm.com, dyoung@redhat.com, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP James, On Wed, Jan 10, 2018 at 11:26:55AM +0000, James Morse wrote: > Hi Akashi, > > 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." > > > > > > Bye! > > (snip...) > > ACPI: Core revision 20170728 > > pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707 > > Internal error: Oops: 96000021 [#1] SMP > > Modules linked in: > > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1 > > task: ffff000008d05180 task.stack: ffff000008cc0000 > > PC is at acpi_ns_lookup+0x25c/0x3c0 > > LR is at acpi_ds_load1_begin_op+0xa4/0x294 > > (snip...) > > Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000) > > Call trace: > > (snip...) > > [] acpi_ns_lookup+0x25c/0x3c0 > > [] acpi_ds_load1_begin_op+0xa4/0x294 > > [] acpi_ps_build_named_op+0xc4/0x198 > > [] acpi_ps_create_op+0x14c/0x270 > > [] acpi_ps_parse_loop+0x188/0x5c8 > > [] acpi_ps_parse_aml+0xb0/0x2b8 > > [] acpi_ns_one_complete_parse+0x144/0x184 > > [] acpi_ns_parse_table+0x48/0x68 > > [] acpi_ns_load_table+0x4c/0xdc > > [] acpi_tb_load_namespace+0xe4/0x264 > > [] acpi_load_tables+0x48/0xc0 > > [] acpi_early_init+0x9c/0xd0 > > [] start_kernel+0x3b4/0x43c > > Code: b9008fb9 2a000318 36380054 32190318 (b94002c0) > > ---[ end trace c46ed37f9651c58e ]--- > > Kernel panic - not syncing: Fatal exception > > Rebooting in 10 seconds.. > > > > (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? (I'm still debugging this code since the kernel fails to boot.) Thanks, -Takahiro AKASHI > > > * ACPI accessor/helper functions are compiled in without unaligned access > > support (ACPI_MISALIGNMENT_NOT_SUPPORTED), eventually ending up a fatal > > panic when accessing ACPI tables. > > > > With this patch, all the reserved memory regions, as well as NOMAP- > > attributed ones which are presumably ACPI runtime code and data, are set > > to be retained in system ram even if they are outside of usable memory > > range specified by device tree blob. Accordingly, ACPI tables are mapped > > as cacheable and can be safely accessed without causing unaligned access > > faults. > > > 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 #include +#include #include #include @@ -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