From patchwork Fri Jun 15 07:56:21 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 138658 Delivered-To: patch@linaro.org Received: by 2002:a2e:970d:0:0:0:0:0 with SMTP id r13-v6csp519325lji; Fri, 15 Jun 2018 00:56:25 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJsMag8mQJ+xeNlgjPcIjSqoFyImAd9uXMCev/8JjypJwgkb3XbBslTpBoLT4O9/rYrdivF X-Received: by 2002:a17:902:8604:: with SMTP id f4-v6mr788807plo.4.1529049385384; Fri, 15 Jun 2018 00:56:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529049385; cv=none; d=google.com; s=arc-20160816; b=zwkcbtJGwSed9numXsRgRcTkEWeS8gvqmg+WuFERBQn72T97ppFtCnHSjbGNw5MhVN YUY1g3bAmbFCwgVgXns04yVrquHIOkg4BNSCrVs+evU28+Uz1Rz0nr+0dn6mR6vfqt4g go2jO+SKcyZr1th8u44UW3s8CUsXjDnLN1fHnEfuBPB4QgiuDmHvqPvVm96yJQ22HZvB qy5BakLgc2p3l4rUoUNXW2KhK4Hy/9MXZdjPvltpGHlUiBpq3b6GrWbs7BEKeslzDtrz 4kXktmuUkTCjeJ1ik/SlG+FLTFTZuDBRKmXCF0MeigHhVBYyDpN/TAshn7jDZH8NJo42 PRCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=fMJ059I9Pwpj92i+n/S50FPN4apoi+2vr23cvPMQsMY=; b=bd540x3Tt7KdGyKNv1YF+AuDxZTXi4rMwvZVFOpkvlU4VgEWjdYaoK9OhSkidcJBaj z046XiWh4B1HbcFyw27N79UUKu9m1Tz7OCMKkap0frDRpNK+c0ZeyFv+CrPBaihp7mo0 g/8Otajx+juEQBEVwqlPqjBgjN/yT2fnW1+AJB8H3hdKugT5fTi+/soI2ywOIt0d6dAL W6a0EFT52ecA877dbxvi3p+gHl6i3y45V8NChEG+btAc0m5idf5mpZNnkrhJNZtvF3E8 QSe32Nbxqa/j1Q8xScSjeAFMZES4B/+8btVNVglFNz7uk+QbL142n7MCMYUrlheqjubC zDDA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=MSoyGnle; 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 e95-v6si7483209plb.239.2018.06.15.00.56.25; Fri, 15 Jun 2018 00:56:25 -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=MSoyGnle; 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 S1755972AbeFOH4X (ORCPT + 30 others); Fri, 15 Jun 2018 03:56:23 -0400 Received: from mail-pg0-f66.google.com ([74.125.83.66]:44976 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755925AbeFOH4U (ORCPT ); Fri, 15 Jun 2018 03:56:20 -0400 Received: by mail-pg0-f66.google.com with SMTP id p21-v6so4078555pgd.11 for ; Fri, 15 Jun 2018 00:56:20 -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:in-reply-to:references; bh=fMJ059I9Pwpj92i+n/S50FPN4apoi+2vr23cvPMQsMY=; b=MSoyGnley1Z1Ck24b5BR2GqAtgAKtiz7OIEKeAAmi9N/0VBXz9l4bS4m9GfK+qr++3 yqK7YlT+Uz+QCQTlZ2k4Sk7/GTm1XwOI7I/IKjh4qKfLrUQIlH22MUmertZG2NGQVAoz +z2cI7j2iEc4gp6W9/NVatyF3Q01o95C9KibQ= 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:in-reply-to :references; bh=fMJ059I9Pwpj92i+n/S50FPN4apoi+2vr23cvPMQsMY=; b=IHjr7WjIFQzXhHBnirVMM4kRoE9/cb4NiRHHbSp9yrX3bX7fXcPY6Pj1SgZWb6vmWJ 2vnYzn9l3iRGex+6VOo+FlaGxGhPHW2cb/HNnVo75n7x1LZimoX/kNmuwr/1B+lQf2hz 59TBeh4jgnWWe34nHN63f5x2Wo8+UB4urVOTMNIzS5DnXzb4M3u//GOb8ADPZyZVfLIV I1cvw7lMDh0x6WNUqRWf5xCKIgRuWGQZNpmMQK8xobjnRABM8/8L6fGzCckjXKIM/us6 CFC3PFieQav1DeH/El0+dRA8ooshgOZ4vmL6KY78JnzjOPSIM1Ng9imy73CvDV8KZsh9 GCUQ== X-Gm-Message-State: APt69E0+eOW4OFakYsYhfSntE4NksIutgg8RC7OEz2O+j/T8vma4bqH0 dpEo1HbzyTE78Zh3rV78Lfbdyw== X-Received: by 2002:a63:7f44:: with SMTP id p4-v6mr595097pgn.416.1529049380265; Fri, 15 Jun 2018 00:56:20 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id d9-v6sm11862437pfg.183.2018.06.15.00.56.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jun 2018 00:56:19 -0700 (PDT) From: AKASHI Takahiro To: catalin.marinas@arm.com, will.deacon@arm.com, akpm@linux-foundation.org, 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 Subject: [PATCH 1/3] arm64: export memblock_reserve()d regions via /proc/iomem Date: Fri, 15 Jun 2018 16:56:21 +0900 Message-Id: <20180615075623.13454-2-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180615075623.13454-1-takahiro.akashi@linaro.org> References: <20180615075623.13454-1-takahiro.akashi@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: James Morse There has been some confusion around what is necessary to prevent kexec overwriting important memory regions. memblock: reserve, or nomap? Only memblock nomap regions are reported via /proc/iomem, kexec's user-space doesn't know about memblock_reserve()d regions. Until commit f56ab9a5b73ca ("efi/arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP") the ACPI tables were nomap, now they are reserved and thus possible for kexec to overwrite with the new kernel or initrd. But this was always broken, as the UEFI memory map is also reserved and not marked as nomap. Exporting both nomap and reserved memblock types is a nuisance as they live in different memblock structures which we can't walk at the same time. Take a second walk over memblock.reserved and add new 'reserved' subnodes for the memblock_reserved() regions that aren't already described by the existing code. (e.g. Kernel Code) We use reserve_region_with_split() to find the gaps in existing named regions. This handles the gap between 'kernel code' and 'kernel data' which is memblock_reserve()d, but already partially described by request_standard_resources(). e.g.: | 80000000-dfffffff : System RAM | 80080000-80ffffff : Kernel code | 81000000-8158ffff : reserved | 81590000-8237efff : Kernel data | a0000000-dfffffff : Crash kernel | e00f0000-f949ffff : System RAM reserve_region_with_split needs kzalloc() which isn't available when request_standard_resources() is called, use an initcall. Reported-by: Bhupesh Sharma Reported-by: Tyler Baicar Suggested-by: Akashi Takahiro Signed-off-by: James Morse Fixes: d28f6df1305a ("arm64/kexec: Add core kexec support") CC: Ard Biesheuvel CC: Mark Rutland --- arch/arm64/kernel/setup.c | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) -- 2.17.0 diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c index 30ad2f085d1f..5b4fac434c84 100644 --- a/arch/arm64/kernel/setup.c +++ b/arch/arm64/kernel/setup.c @@ -241,6 +241,44 @@ static void __init request_standard_resources(void) } } +static int __init reserve_memblock_reserved_regions(void) +{ + phys_addr_t start, end, roundup_end = 0; + struct resource *mem, *res; + u64 i; + + for_each_reserved_mem_region(i, &start, &end) { + if (end <= roundup_end) + continue; /* done already */ + + start = __pfn_to_phys(PFN_DOWN(start)); + end = __pfn_to_phys(PFN_UP(end)) - 1; + roundup_end = end; + + res = kzalloc(sizeof(*res), GFP_ATOMIC); + if (WARN_ON(!res)) + return -ENOMEM; + res->start = start; + res->end = end; + res->name = "reserved"; + res->flags = IORESOURCE_MEM; + + mem = request_resource_conflict(&iomem_resource, res); + /* + * We expected memblock_reserve() regions to conflict with + * memory created by request_standard_resources(). + */ + if (WARN_ON_ONCE(!mem)) + continue; + kfree(res); + + reserve_region_with_split(mem, start, end, "reserved"); + } + + return 0; +} +arch_initcall(reserve_memblock_reserved_regions); + u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID }; void __init setup_arch(char **cmdline_p) From patchwork Fri Jun 15 07:56:22 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 138659 Delivered-To: patch@linaro.org Received: by 2002:a2e:970d:0:0:0:0:0 with SMTP id r13-v6csp519584lji; Fri, 15 Jun 2018 00:56:45 -0700 (PDT) X-Google-Smtp-Source: ADUXVKK1D/NSw6yUTGuSgOKX7vybQc+R1O1kIrTz6qCQ4cbSA25VHJkXFcBK3XVsWF7eIDH0zCCm X-Received: by 2002:a65:5085:: with SMTP id r5-v6mr599886pgp.123.1529049405370; Fri, 15 Jun 2018 00:56:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529049405; cv=none; d=google.com; s=arc-20160816; b=vQfxg1Qk7RlIQYRq1n2CUZXmy4h+EeX5jCg/vyS/t6Uc4VBCQtEJSVyUSJoL+1zDWw jrgEtqE65gc2ja3IKsECVeqcIVopNazGAD44qcP0Caoc0IgeV2aXtCwsR7Bp0GxbR6Y6 ofem/TGG79GQ+cp2jYq8NVP8980f+NBHkxE7kO7bImIS889k474yiwDBCJPiUYCwDfD7 ZgA34n2Xu9uW54gLYzkCIYy0CKt6QmaKsCOskujGFQ/7mlCTjlAeK8tuixt/h9Wq5v7s wVqAMDJcbRVqvDfbA3i3aTsAambTOb3OtLeEuZrf/fq7G/uYBoCC75uawjEH4E7L18jq i9+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=SVvccCNZOnC10fldZUKI5r72hoQShNewrJAgWxAVx0g=; b=flLiEQjJvEhpPDpdP9WORppZ72XW0F231oAseh6ER4a/E6Y3h/cwffk0VoYLJi+teY XXN/6l5Ph0Hys6zyCAA0izE9eZcvK/bHtCMRWLZPS8a4Re0DQ0bYo1GCfYvnmJckSIkB tB5h/UeYtIatVp+80qsXbaJHVYWpURBLBVd8xsUPoBTmoGhaB5QMpiO53SqeoLyWACan 6mFc+tTWiv1iO+o7qaAswEguTC9fGYyJfgO9ZzCp3wmSjjkmr3LHgPz/5XOrYCYWkYSy Uasyj9ADYmlFoubW28TDhTivNqJKyPhIQUBSq1LfJSMxJ4PkDXiC0JqwR0DRnLV1CI+2 PURA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=BantF8Xs; 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 e95-v6si7483209plb.239.2018.06.15.00.56.45; Fri, 15 Jun 2018 00:56:45 -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=BantF8Xs; 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 S1755983AbeFOH4n (ORCPT + 30 others); Fri, 15 Jun 2018 03:56:43 -0400 Received: from mail-pl0-f67.google.com ([209.85.160.67]:35315 "EHLO mail-pl0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755925AbeFOH4k (ORCPT ); Fri, 15 Jun 2018 03:56:40 -0400 Received: by mail-pl0-f67.google.com with SMTP id k1-v6so4963948plt.2 for ; Fri, 15 Jun 2018 00:56:40 -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:in-reply-to:references; bh=SVvccCNZOnC10fldZUKI5r72hoQShNewrJAgWxAVx0g=; b=BantF8Xs7NOjMKaFxleSbjk2rLcJvSWCo8wd55fvdPU8TXQrASc1uXwtzrQnzQWjPy ir9hqnD+0wPEZWsz9G/EMRSgPeTJHvLpkcqDzmOpnHbla9ZsnY++6R7UVePVXk2TTlzG A9VQi9RvzS0kPWA4Uhbk6I7QYi4YTz9gTXB0Y= 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:in-reply-to :references; bh=SVvccCNZOnC10fldZUKI5r72hoQShNewrJAgWxAVx0g=; b=loqI/M8kopc15YXTDUbzgISF/sEMseZBUNbenBta3L/5ZVwqxMFNC7OMYs36CPrUoC 82VUaPa9zRCi5c1+JH7k+XQl+hFHNpA2mSkr+L4lt/IWz+sAAbtOi6AUkeaE8j6BnGsZ vJQ67KH3EA2vKpakqE14jMPyetKoQuOsIC+MN3vdEdBzJLC36d6bO8vcLL4TR27v00lZ Dg1/7grdHZyg2Ox0R+e+0MQH5gwRCRvmfzwoa8mb1H5CdR9CVpnODz5Zll+CqRqnZfmL ooVR7KaZlJ14KSdLuIRfIphd7SJBQC4L+Iv7tIrtxTyTtM1nVQ8YsiqQbwy0DETRFv7q 5RSg== X-Gm-Message-State: APt69E29A4Oy0vMSwYM2EkxP2JwUZqScxGybNvmImT8iLGMV0kXBkkTY +RZpjWXdvPlj/3E4f60LYeYfYw== X-Received: by 2002:a17:902:7105:: with SMTP id a5-v6mr758104pll.171.1529049400174; Fri, 15 Jun 2018 00:56:40 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id t68-v6sm13357123pfe.91.2018.06.15.00.56.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jun 2018 00:56:39 -0700 (PDT) From: AKASHI Takahiro To: catalin.marinas@arm.com, will.deacon@arm.com, akpm@linux-foundation.org, 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 2/3] arm64: acpi, efi: fix alignment fault in accessing ACPI tables at kdump Date: Fri, 15 Jun 2018 16:56:22 +0900 Message-Id: <20180615075623.13454-3-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180615075623.13454-1-takahiro.akashi@linaro.org> References: <20180615075623.13454-1-takahiro.akashi@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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." (kernel messages after panic kicked off kdump) (snip...) 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 are differently handled as they are "memblock-reserved", without NOMAP bit. * So they are now excluded from device tree's "usable-memory-range" which kexec-tools determines based on a current view of /proc/iomem. * When crash dump kernel boots up, it tries to accesses ACPI tables by mapping them with ioremap(), not ioremap_cache(), in acpi_os_ioremap() since they are no longer part of mapped system ram. * Given that ACPI accessor/helper functions are compiled in without unaligned access support (ACPI_MISALIGNMENT_NOT_SUPPORTED), any unaligned access to ACPI tables can cause a fatal panic. With this patch, acpi_os_ioremap() always honors memory attribute information provided by the firmware (EFI) and retaining cacheability allows the kernel safe access to ACPI tables. Please note that arm_enable_runtime_services() is now renamed to efi_enter_virtual_mode() due to the similarity to x86's. Signed-off-by: AKASHI Takahiro Suggested-by: James Morse Suggested-by: Ard Biesheuvel Reported-by and Tested-by: Bhupesh Sharma (for older version) --- arch/arm64/include/asm/acpi.h | 23 ++++++++++++++++------- arch/arm64/kernel/acpi.c | 11 +++-------- drivers/firmware/efi/arm-runtime.c | 27 ++++++++++++--------------- 3 files changed, 31 insertions(+), 30 deletions(-) -- 2.17.0 diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h index 32f465a80e4e..d53c95f4e1a9 100644 --- a/arch/arm64/include/asm/acpi.h +++ b/arch/arm64/include/asm/acpi.h @@ -12,10 +12,12 @@ #ifndef _ASM_ACPI_H #define _ASM_ACPI_H +#include #include #include #include +#include #include #include @@ -29,18 +31,22 @@ /* 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) { + /* For normal memory we already have a cacheable mapping. */ + if (memblock_is_map_memory(phys)) + return (void __iomem *)__phys_to_virt(phys); + /* - * EFI's reserve_regions() call adds memory with the WB attribute - * to memblock via early_init_dt_add_memory_arch(). + * We should still honor the memory's attribute here because + * crash dump kernel possibly excludes some ACPI (reclaim) + * regions from memblock list. */ - 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 +131,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 7b09487ff8fb..ed46dc188b22 100644 --- a/arch/arm64/kernel/acpi.c +++ b/arch/arm64/kernel/acpi.c @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include @@ -29,13 +30,9 @@ #include #include +#include #include -#ifdef CONFIG_ACPI_APEI -# include -# include -#endif - int acpi_noirq = 1; /* skip ACPI IRQ initialization */ int acpi_disabled = 1; EXPORT_SYMBOL(acpi_disabled); @@ -239,8 +236,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 +257,3 @@ pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr) return __pgprot(PROT_NORMAL_NC); return __pgprot(PROT_DEVICE_nGnRnE); } -#endif diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c index 5889cbea60b8..566ef0a9edb5 100644 --- a/drivers/firmware/efi/arm-runtime.c +++ b/drivers/firmware/efi/arm-runtime.c @@ -106,46 +106,43 @@ static bool __init efi_virtmap_init(void) * non-early mapping of the UEFI system table and virtual mappings for all * EFI_MEMORY_RUNTIME regions. */ -static int __init arm_enable_runtime_services(void) +void __init efi_enter_virtual_mode(void) { u64 mapsize; if (!efi_enabled(EFI_BOOT)) { pr_info("EFI services will not be available.\n"); - return 0; + return; + } + + mapsize = efi.memmap.desc_size * efi.memmap.nr_map; + + if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) { + pr_err("Failed to remap EFI memory map\n"); + return; } if (efi_runtime_disabled()) { pr_info("EFI runtime services will be disabled.\n"); - return 0; + return; } if (efi_enabled(EFI_RUNTIME_SERVICES)) { pr_info("EFI runtime services access via paravirt.\n"); - return 0; + return; } pr_info("Remapping and enabling EFI services.\n"); - mapsize = efi.memmap.desc_size * efi.memmap.nr_map; - - if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) { - pr_err("Failed to remap EFI memory map\n"); - return -ENOMEM; - } - if (!efi_virtmap_init()) { pr_err("UEFI virtual mapping missing or invalid -- runtime services will not be available\n"); - return -ENOMEM; + return; } /* Set up runtime services function pointers */ efi_native_runtime_setup(); set_bit(EFI_RUNTIME_SERVICES, &efi.flags); - - return 0; } -early_initcall(arm_enable_runtime_services); void efi_virtmap_load(void) { From patchwork Fri Jun 15 07:56:23 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 138660 Delivered-To: patch@linaro.org Received: by 2002:a2e:970d:0:0:0:0:0 with SMTP id r13-v6csp519665lji; Fri, 15 Jun 2018 00:56:52 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKic2F+x979IBsaKKGay2Atm2DYxi8jGMkDTGyqxqqAH6jKyCYn8yMvQZNmOLwqlm5XRaYL X-Received: by 2002:a62:ca99:: with SMTP id y25-v6mr697182pfk.187.1529049412036; Fri, 15 Jun 2018 00:56:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529049412; cv=none; d=google.com; s=arc-20160816; b=HxG+DVMAfP9+M39k9Ce2ysH/78WfL4q1eVwyJpKBZQojYPLjhZDg6kB3a92SNBNOL+ DLs54fOiessU+kog3OlE+XQ/bF1w5y7mnjQ5z72tADMkZtbKUlEMDHzVPTiQkHK/mI3C SAPUO0bBUtJSaqdAAIcHCj4SMS87uO+mAxxsq3/p4hjRbC2pAHHtlowbivcpyJWbqjxY ltUQh/7cZXOr+DBDPviUzA0aVuqUxSAAWFDWN/EVfkpMgcJRZJxK4NHxYWK0wteRqrSi vXCjVcMukuxufXB6KnV4EfDnF/YAYfDG208seEr+6bEznyOifmPrUUvqnk5okGiP1z1r bKng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=kpMEU3sh1IN0/bxn4qA0OTMbmXCEF6TENF+YzCU+lOw=; b=LX2ok2ISzbYGbZ+YB/R/OFe8hIWYvFLvygqpyBawJNesiHp+mXgeC2EIMOJurxJZ4e 4wZjAFmGsJ+998cAwR2TMoyhMAB9leyMh06DRmvaPH/hFOYSUmw1s24yCIXZT6c7ZGnV 8O+/YiC9vQigF02OgDwE/CPdwLPCHS6TG/nBtjTKAJI/Dep9Mqq8yMR9kagT4eP7QowC xvQhiaXUlVFqf4WICxo8LD7i8Fgtj5MSS1bHa/Z3poF7cpSq+Uc657szobW996YEsCR9 Yb+rCLmFiYfT9koBUUAXbkbdstKWVV89ihurK7m7ENHSL7LqtLh+w977BXxeqPMLGXP7 CYfA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=DDBvU4rz; 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 s36-v6si7178751pld.278.2018.06.15.00.56.51; Fri, 15 Jun 2018 00:56:52 -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=DDBvU4rz; 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 S1755997AbeFOH4t (ORCPT + 30 others); Fri, 15 Jun 2018 03:56:49 -0400 Received: from mail-pl0-f66.google.com ([209.85.160.66]:38658 "EHLO mail-pl0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755925AbeFOH4q (ORCPT ); Fri, 15 Jun 2018 03:56:46 -0400 Received: by mail-pl0-f66.google.com with SMTP id b14-v6so4941502pls.5 for ; Fri, 15 Jun 2018 00:56:45 -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:in-reply-to:references; bh=kpMEU3sh1IN0/bxn4qA0OTMbmXCEF6TENF+YzCU+lOw=; b=DDBvU4rzCp9e+l19e+pORcW+cEFywfs3fb1wjwtB8DcbVZiIj/KWS2WMhIhSSDm9Me ti+Jj+TCb7ZdaLMoEx0z4oA0I+WJD19fKOV3JNOEiNDyh0/fxx3rBVO7iaWDeYyiqmpy r0zFGt6g/zJ6D14WTbXzhgA6ggN9IjbAvowqY= 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:in-reply-to :references; bh=kpMEU3sh1IN0/bxn4qA0OTMbmXCEF6TENF+YzCU+lOw=; b=j3KCcr0OT3mUrx6HgXbuhv8ktRvLOV585k2vkTrPlyUIMWbTT49vobc4f6dqhQmN1I ALF4qd4lcqFRtz6hMtqoR4r+EVyRxJVK+oS4wq/l8F6/iFt5JMdJ51Y588let+9zrqmG pUtdL86l3PGaSgO/TTefsN0w37Vg3fsOCV/58AE8Owqdo/BBzfwkVI14atRcrhmXoNme CkwHOfqSQY5p5Hnb0O5+unv+sK7oWcnn5Ck6oB2pKT5TZEVubpzvcm2Jv+TIDhf5Aq4d /wOM4VbtqmHKxufso90ATR3Kaxd1HTyg5mv6dDid1Y2wRkhkagfql2RLkTop60tirKw8 Qi9w== X-Gm-Message-State: APt69E2SH7Lu1wip7IziMwwRQm5GO8j04lh6R0pQ8oPb56oYTfGU6Uv2 EklhywxMh3qlnaiM0YnHNNsm6w== X-Received: by 2002:a17:902:9048:: with SMTP id w8-v6mr788087plz.34.1529049405314; Fri, 15 Jun 2018 00:56:45 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id s2-v6sm12872638pfb.127.2018.06.15.00.56.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jun 2018 00:56:44 -0700 (PDT) From: AKASHI Takahiro To: catalin.marinas@arm.com, will.deacon@arm.com, akpm@linux-foundation.org, 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 3/3] init: map UEFI memory map early if on arm or arm64 Date: Fri, 15 Jun 2018 16:56:23 +0900 Message-Id: <20180615075623.13454-4-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180615075623.13454-1-takahiro.akashi@linaro.org> References: <20180615075623.13454-1-takahiro.akashi@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org As ACPI tables may not always be properly aligned, those regions should be mapped cacheable in order to allow the kernel safe access to them. UEFI memory map contains necessary information for mappings, and we want to make sure that it should get accessible before any acpi_os_ioremap()'s. So, in this patch, efi_enter_virtual_mode(), which was previously named efi_enable_runtime_services() and invoked via early_initcall on arm/arm64, is now moved early enough as the first access will occur in acpi_load_tables() of acpi_early_init(). See a relevant commit: arm64: acpi,efi: fix alignment fault in accessing ACPI tables at kdump Signed-off-by: AKASHI Takahiro Suggested-by: Ard Biesheuvel Cc: Andrew Morton --- init/main.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.17.0 diff --git a/init/main.c b/init/main.c index 3b4ada11ed52..532fc0d02353 100644 --- a/init/main.c +++ b/init/main.c @@ -694,6 +694,9 @@ asmlinkage __visible void __init start_kernel(void) debug_objects_mem_init(); setup_per_cpu_pageset(); numa_policy_init(); + if (IS_ENABLED(CONFIG_EFI) && + (IS_ENABLED(CONFIG_ARM64) || IS_ENABLED(CONFIG_ARM))) + efi_enter_virtual_mode(); acpi_early_init(); if (late_time_init) late_time_init();