From patchwork Mon Jul 9 00:07:47 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 141352 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp2054325ljj; Sun, 8 Jul 2018 17:07:04 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfjR0E5ZjbRvzDYtnEqLV6k3q8c1jzgTtvAB5I7mxoAYBh+nLfC4v+4rxvJIiYZr1XObWu5 X-Received: by 2002:a65:6110:: with SMTP id z16-v6mr12449024pgu.412.1531094824270; Sun, 08 Jul 2018 17:07:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531094824; cv=none; d=google.com; s=arc-20160816; b=tAfab+cyLM5kBKFb1tiX30IIBlOJF/REaulKQOF4xqPbypHB2zU0peQikMqq0qPV+c EF5ryNIWdzYUMjeLnK49iwoUwqfVm2xtICPQ8eyW6RasOGvrR0z7cN8ha2gTdXE/jNg9 Tu+iIbLd4jG5Fs9WZyYv2W/7/SAsngbeQKMrTdHKqqnpRRL+FldAZZmv5ulrgHTDWzMU hYNKm8YgFjaUsCHFLfNlDBNwYXJlk16dESxRG46Qnu2SrFEVUaFaAvUrxstnlg5a4g3V Al0FZmb1oq7A5u0cwNsenwGvsBKguzRlKC6kXeMjVt2Dk5Lds2WFI98GycbZIVNn8f0I yZCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=TBYYWNIunOPOXXp1h6GYsMejT/InhEEpQzf9z0Ky6F4=; b=YYLYnfNBQRhMHTfAWFea41Iw426fFzphw5HmIX65y97SjP/2BRNWclFLaltrVrFQlQ 2uwfKeuCWUUvWEHZ9pIbuiiS0OBQCcggmwp+QwBgHf6osn/5O+GhAxExRzJkfoE6mBuZ XbEVHIypRsURfxu8I1nYmV2VV12xRGKP/VIYVfUhtNS8LYTJhyf3vdSnmBCkg2magpdQ dggyd17o/H6itMMBVckZE/yiDoaCSq9lH0Iqmd9sytygFjFOw8IMSN6RGj2FKijslcyf aGwGvTdqw6LdgkN8cj1HCe88cUK/rcc3slp7aBOk/TcYjnTZvyW7itkf5PjE4sGlFTlg 2xSA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=jVcH4sJv; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g75-v6si10758189pfb.37.2018.07.08.17.07.03; Sun, 08 Jul 2018 17:07:04 -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; dkim=pass header.i=@linaro.org header.s=google header.b=jVcH4sJv; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933267AbeGIAHC (ORCPT + 28 others); Sun, 8 Jul 2018 20:07:02 -0400 Received: from mail-pf0-f195.google.com ([209.85.192.195]:34705 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932942AbeGIAHB (ORCPT ); Sun, 8 Jul 2018 20:07:01 -0400 Received: by mail-pf0-f195.google.com with SMTP id e10-v6so12321476pfn.1 for ; Sun, 08 Jul 2018 17:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=TBYYWNIunOPOXXp1h6GYsMejT/InhEEpQzf9z0Ky6F4=; b=jVcH4sJv17jSOUoiyCvAvovrFxd2HkSeGyFTTvOo6isZJ1jVCo8ql86ZaMmZ/zRjLC 9x4em3OQ2ass6ZXCSQpTpIAKY9poVWRCG3dTyZxzuC5IKlv5N6NJ4teeY2Ontv1xY2eN y+CXLtqcK9eOh+U6RemiOVmrklbxA2Eab9/Hs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=TBYYWNIunOPOXXp1h6GYsMejT/InhEEpQzf9z0Ky6F4=; b=B0mHWuGPkAODhbZ0Q+f1m9PXzDAFkbi2MjzfNZDzJFPoLiWk9XfSPZAXZidOSBDg4Y 6cy2tZ+m/hC/g1Sp8nfGxdv68rQUvhxnrcqwFQvaab6l4gnSYe2RXZ0jDhFWAEG0Aj+k HoAExfEmP0DvWcTjVwD5aQnl8UfUDDN4XHBB/3ujUZkWINx56nZ0ZRB4pTSEFq1mtcV7 EniFnG2KJqXefWBhSLDS9mdq8wWIgBjj5nsCAPfeqP8nTMf3uT7Uj92/WHY0og1CKfW6 H1XxkF0bwnzt24vVl5ny094foY6foi3/EaYP5cCzxrrg8vllY3bWftsS+3wzBNhAhxXq 64Cg== X-Gm-Message-State: APt69E30ed4M89npUd54VaHtC4ThNEkvtAnNlj3yskeUkEQJIArN4hs8 jMKO5RYx1Id7rwMZAuomGtc7wXoisgo= X-Received: by 2002:a63:5c10:: with SMTP id q16-v6mr16830370pgb.452.1531094820511; Sun, 08 Jul 2018 17:07:00 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id e82-v6sm31423474pfd.40.2018.07.08.17.06.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Jul 2018 17:06:59 -0700 (PDT) From: AKASHI Takahiro To: catalin.marinas@arm.com, will.deacon@arm.com, ard.biesheuvel@linaro.org Cc: tbaicar@codeaurora.org, bhsharma@redhat.com, dyoung@redhat.com, james.morse@arm.com, mark.rutland@arm.com, al.stone@linaro.org, graeme.gregory@linaro.org, hanjun.guo@linaro.org, lorenzo.pieralisi@arm.com, sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, AKASHI Takahiro Subject: [PATCH v3 0/3] arm64: kexec, kdump: fix boot failures on acpi-only system Date: Mon, 9 Jul 2018 09:07:47 +0900 Message-Id: <20180709000750.22172-1-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.17.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. User-space can tell the difference between reserved-system-ram and reserved-address-space.) * 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]. --- more words from James --- Our attempts to fix this just in the kernel reached a dead end, because Kdump needs to include reserved-system-ram, whereas kexec has to avoid it. User-space needs to be able to tell reserved-system-ram and reserved-address-space apart. Hence we need to expose that information, and pick it up in user-space. Patched-kernel and unpatch-user-space will work the same way it does today, as the additional reserved regions are ignored by user-space. Unpatched-kernel and patched-user-space will also work the same way it does today as the additional reserved regions are missing. --->8--- 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. Ard's patch [4] needs to be applied preliminarily. Changes in v3 (2018, July 9, 2018) * drop the v2's patch#3, preferring [4] Changes in v2 (2018, June 19, 2018) * re-organise v1's patch#2 and #3 into v2's #2, #3 and #4 not to break bisect [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 [4] https://marc.info/?l=linux-efi&m=152930773507524&w=2 AKASHI Takahiro (2): efi/arm: map UEFI memory map even w/o runtime services enabled arm64: acpi: fix alignment fault in accessing ACPI 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 | 14 +++++------ 4 files changed, 64 insertions(+), 22 deletions(-) -- 2.17.0