Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp755155imm; Fri, 15 Jun 2018 05:53:11 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIhJvSrFpADFjYKbdMmySF28bKMe9O4qyzzTwtDe3sxPujgo3FAazkvC/lfu3gQYkKicX1N X-Received: by 2002:a63:9741:: with SMTP id d1-v6mr1457875pgo.403.1529067190839; Fri, 15 Jun 2018 05:53:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529067190; cv=none; d=google.com; s=arc-20160816; b=ZOdEgOQ4rGbRIIT/ea51MHq3TQ7BxXWqfzqpLk1pmcPxu59+7ccOqqJf0ke8J2BneH aUCd9jJYJIwawxtOWYTPDzeIWzkBr0Z1ACIXNeEkiI3ISY4BMME8BZ934qDpcwTSd8R0 9n4878f4NTJZxgeKMAoR71jlxyl3M9HySOxlTaR0yO6/LRsreMDJImi1Uk/BoKye/+OP GjiArmn1kmZqjzpsJyFDrH6mr9Xb9gsJSSxQYShYIFuZ/zdgx18qq2CTg7LtE3itg7/N hPhJiN/MXeD6FoclIjv33cMnblyA1tvJkQM6E1bqCyC84p+W7fZ9/KSe0H8FGa4k3on5 CFjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:arc-authentication-results; bh=0Utll6ofGCXbQpMI0zrypqOdyUpSoC95d9PTXaJ3wf8=; b=Y/vD0hqItCpZI4jzG53aN0vAhjfGVN3tAhV1pOdAsWpItjzDFyQ3gE+9RJGNVrhW/W t4AGB5+Pnk8FI3FQ+wfSJ2I9qDqjBOuA6wGt98JjeHIzfqTd9VIM3gzKxX0StYj3WOBp ofnYTMkUi/jdBW7GQd9AKQcnSmCwCKlh3j33YUbsp4qpuTHAqmmINP/S0coNvzrHY/l6 96weMS7qQGE8PdzKJvGcXt+1cGymLPwwPs2q572luGA79y9FBGcNgErqC1LT8fQizy/l XipMZ4Iz1x4DcI8JzY74uuA1As/X7hV3W13jhlrCVeLbCeqpGOfaPw92Xabd7DoUHCO1 m9Hg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s10-v6si6630005pgf.225.2018.06.15.05.52.55; Fri, 15 Jun 2018 05:53:10 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756145AbeFOMwF (ORCPT + 99 others); Fri, 15 Jun 2018 08:52:05 -0400 Received: from mail-lf0-f67.google.com ([209.85.215.67]:37616 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755850AbeFOMwE (ORCPT ); Fri, 15 Jun 2018 08:52:04 -0400 Received: by mail-lf0-f67.google.com with SMTP id g21-v6so14499955lfb.4 for ; Fri, 15 Jun 2018 05:52:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0Utll6ofGCXbQpMI0zrypqOdyUpSoC95d9PTXaJ3wf8=; b=RFoWwHlQD5jz+Dmuz9Xw0/TKtYt6XFBgU/inaGAgye8Mmod6t2/p2WksDPqnGaLxFJ q7Zahh7zyLJhz670yST3uMin4C8k4PYm+E0DtTGHmj7LKYdbhEnrlKA0DWBAPSyE0Am9 hzzjIQg8mGmBmqXDYG9gjF/OwbCfi0zIhj4yWuGWptj9JPNiHzyBBINDhTeMa0sLXk6B vKIICA7SGnzBvS5j1bKroS4utUGog9SLp74b5MGR0rm/MtX86hNDL0c1MzxODH5XTUbR JlBiOHOiN7jFN5E4kSqV2LFPMqPyjMXjagWEnf3gdUl+cLLl1sTuWR1Tmk2YOM9InI+O CqAg== X-Gm-Message-State: APt69E2dxm0sKYJgQtIsZDjQGRkAf4oK5IpE9vtVaXy0y1lt50g0yNWj 6Q5pIEKlKLC2OyrDFzoB6GO4UzPo65SnW59PHrB0Nw== X-Received: by 2002:a2e:161d:: with SMTP id w29-v6mr1331571ljd.105.1529067122867; Fri, 15 Jun 2018 05:52:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:898a:0:0:0:0:0 with HTTP; Fri, 15 Jun 2018 05:52:02 -0700 (PDT) In-Reply-To: <20180615075623.13454-1-takahiro.akashi@linaro.org> References: <20180615075623.13454-1-takahiro.akashi@linaro.org> From: Bhupesh Sharma Date: Fri, 15 Jun 2018 18:22:02 +0530 Message-ID: Subject: Re: [PATCH 0/3] arm64: kexec,kdump: fix boot failures on acpi-only system To: AKASHI Takahiro Cc: Catalin Marinas , Will Deacon , akpm@linux-foundation.org, Ard Biesheuvel , tbaicar@codeaurora.org, Dave Young , James Morse , Mark Rutland , al.stone@linaro.org, graeme.gregory@linaro.org, hanjun.guo@linaro.org, lorenzo.pieralisi@arm.com, sudeep.holla@arm.com, linux-arm-kernel , Linux Kernel Mailing List , kexec mailing list Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Akashi, Thanks for the patchset - we have been waiting for quite some time for this fix so that crashkernel can boot on arm64 machines which support boot'ing via ACPI tables. I have tested this on my huawei-taishan arm64 board, so: Tested-by: Bhupesh Sharma BTW, if possible I would suggest to use: Reported-by: Bhupesh Sharma rather than: Reported-by: Bhupesh Sharma Thanks, Bhupesh On Fri, Jun 15, 2018 at 1:26 PM, AKASHI Takahiro wrote: > # apologies for a bit late updates > > This patch series is a set of bug fixes to address kexec/kdump > failures which are sometimes observed on ACPI-only system and reported > in LAK-ML before. > > In short, the phenomena are: > 1. kexec'ed kernel can fail to boot because some ACPI table is corrupted > by a new kernel (or other data) being loaded into System RAM. Currently > kexec may possibly allocate space ignoring such "reserved" regions. > We will see no messages after "Bye!" > > 2. crash dump (kdump) kernel can fail to boot and get into panic due to > an alignment fault when accessing ACPI tables. This can happen because > those tables are not always properly aligned while they are mapped > non-cacheable (ioremap'ed) as they are not recognized as part of System > RAM under the current implementation. > > After discussing several possibilities to address those issues, > the agreed approach, in my understanding, is > * to add resource entries for every "reserved", i.e. memblock_reserve(), > regions to /proc/iomem. > (NOMAP regions, also marked as "reserved," remains at top-level for > backward compatibility.) > * For case (1), user space (kexec-tools) should rule out such regions > in searching for free space for loaded data. > * For case (2), the kernel should access ACPI tables by mapping > them with appropriate memory attributes described in UEFI memory map. > (This means that it doesn't require any changes in /proc/iomem, and > hence user space.) > > Please find past discussions about /proc/iomem in [1]. > > Patch#1 addresses kexec case, for which you are also required to update > user space. See necessary patches in [2]. If you want to review Patch#1, > please also take a look at and review [2]. > > Patch#2 and #3 addresses kdump case. This is a revised version after > Ard's comments.[3] > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-March/565980.html > [2] https://git.linaro.org/people/takahiro.akashi/kexec-tools.git arm64/resv_mem > [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-April/573655.html > > AKASHI Takahiro (2): > arm64: acpi,efi: fix alignment fault in accessing ACPI tables at kdump > init: map UEFI memory map early if on arm or arm64 > > James Morse (1): > arm64: export memblock_reserve()d regions via /proc/iomem > > arch/arm64/include/asm/acpi.h | 23 ++++++++++++------ > arch/arm64/kernel/acpi.c | 11 +++------ > arch/arm64/kernel/setup.c | 38 ++++++++++++++++++++++++++++++ > drivers/firmware/efi/arm-runtime.c | 27 ++++++++++----------- > init/main.c | 3 +++ > 5 files changed, 72 insertions(+), 30 deletions(-) > > -- > 2.17.0 >