From patchwork Mon Jul 9 23:42:25 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 141493 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp3204895ljj; Mon, 9 Jul 2018 16:41:54 -0700 (PDT) X-Google-Smtp-Source: AAOMgpd5kkpDb8zNHPsBgLYZduuxWN06+CX9VFKg4Z4gFcTQQRfBL4XqdvyCJaMUqxn8/wr+2T0p X-Received: by 2002:a17:902:bd42:: with SMTP id b2-v6mr22310148plx.23.1531179714510; Mon, 09 Jul 2018 16:41:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531179714; cv=none; d=google.com; s=arc-20160816; b=LvJvtj7tHQLGcVr4QMy09QGsSCQSdLgUVew/QtpixmKMCyfFxtdzDEQsKdwnxTOPf7 WB9qNSB5brLam6EO1JLLjdfZdXwt1tDCpm8W5nX/Uy1zY1/TZzrx2k6kS5QAmlSGjNrX N8E9tA2ccP2MAv944EUHFZVNJP/WoCh8TA98RUnjFlE64Z2pPzjCK++E2sNyT1WbWVmc qydrtV4ABmQ6ZGYzt+Q8BlGghG59fiGmtfwwAq8tTko47hcOfdG7g8DOuYhhgVTYr4EQ jnz8MDL9h5hmvhQfrxNSgvobyy5UTplVx34eEPWCuZhFWNfKv9EQ89nhMa70F7ZsNC8V mSmg== 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=Uj8pkoBOXKQmwupl7YG3aqymyd/MK8TVdoF/8RiGvT4=; b=ZYsfJEbRv2xuZGAgoIuk6nFe7xr6BW8PR7frtsWlHI97BMVy+m16rQs2rGUgl2DmnI P7GHib0LIEWpwKtw0qcK+GswTKdwo/QjBqvLH1v3buKWp96rwKDcO0eKxU4BIKDu7mIJ NpCJ7qUEK45hAVpasOsA6GUV30EF8+sFJw4shRjfpJF1P0lSmE55QKTBCCUEz8rSt9Vk NYjoCC3tY4aUtcPZlvGVRI04uNRSFWHVWJTtOinK67DTYgGUNpjuIFrqoU8O1eS4aAgq f463+Pfiqwow/wIGYgXF/zpwo0u3riBAPKK1h8g2obgBrbzp6w6TshzE8ocFlrA6yV6u q8rA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=HR+Y3Em1; 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 a72-v6si14901550pge.497.2018.07.09.16.41.54; Mon, 09 Jul 2018 16:41:54 -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=HR+Y3Em1; 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 S933206AbeGIXl0 (ORCPT + 12 others); Mon, 9 Jul 2018 19:41:26 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:37873 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932828AbeGIXlY (ORCPT ); Mon, 9 Jul 2018 19:41:24 -0400 Received: by mail-pf0-f196.google.com with SMTP id x10-v6so4876276pfm.4 for ; Mon, 09 Jul 2018 16:41:24 -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=Uj8pkoBOXKQmwupl7YG3aqymyd/MK8TVdoF/8RiGvT4=; b=HR+Y3Em1Hdfd65aIcIpkGY4ItH3sOUVXnC7IpduN1OekVf4p3YfCn1hcEoata0FyYM 5y0U9bW6h+kILery3o7CEfuxCENHZ4flX0Jvb+B75P6V4MduWh6gxIBS9FWStDy4ZlTA OB8DzHpYtYh4FXeF/eUAyo4U9Pyzqtqb7qEg4= 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=Uj8pkoBOXKQmwupl7YG3aqymyd/MK8TVdoF/8RiGvT4=; b=Ft9vj92/L9RWcyfCaqTKxwQs24j9PnAvd3YITeIsHgh8qvvvJ3pY8uJXLvmCYIJbEY rL51IsGRs9uM/0a7FE39c8liw5r4NrZVwKmkTAbelKx3N2Jr8g5tfVeL1P/QGf62srL6 05mHcpO9dnRP5samq0OVSMmnUFOXL2On7HH9ZEK5Z6EpkG1zHLImdEQv8gYrpbzGfc9G 2Tfk381sskkx1zwj72Zm7cRcSDJUXc9oIGnC6Mx3giCOIfsowhWRKM1NJTrAn2XBXvPp 1G72YIo2832aQum/0hGLuaFqMBiW4y4R4CCcCn+QV59TYtNrvMazR/LzNqiroQjS0Ond AApw== X-Gm-Message-State: APt69E1fB6XWJGcyBO+IDVoqk1lyhNlqpmqcp/67MV83yrBfq+A5AoSg eAbLNTGwVHRw4iGO2UAdlbBQLw== X-Received: by 2002:a63:d309:: with SMTP id b9-v6mr7212965pgg.163.1531179684071; Mon, 09 Jul 2018 16:41:24 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id t3-v6sm29062690pfk.161.2018.07.09.16.41.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 16:41:23 -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.1 0/4] arm64: kexec, kdump: fix boot failures on acpi-only system Date: Tue, 10 Jul 2018 08:42:25 +0900 Message-Id: <20180709234229.20181-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, #3 and #4 address the kdump case above. Changes in v3.1 (2018, July 10, 2018) * add Ard's patch[4] to this patch set 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 Ard Biesheuvel (1): efi/arm: preserve early mapping of UEFI memory map longer for BGRT 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-init.c | 1 - drivers/firmware/efi/arm-runtime.c | 16 +++++++------ 5 files changed, 66 insertions(+), 23 deletions(-) -- 2.17.0