From patchwork Tue Jun 19 06:44: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: 139088 Delivered-To: patch@linaro.org Received: by 2002:a2e:970d:0:0:0:0:0 with SMTP id r13-v6csp4837326lji; Mon, 18 Jun 2018 23:46:12 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLdjCv+8YmjFGVUrnJUkGXPYSnS2yEd9qgSl6164/G6HXstlQE51qNUlBC/6T99HC0e2BSU X-Received: by 2002:a17:902:9a8a:: with SMTP id w10-v6mr17413609plp.333.1529390772387; Mon, 18 Jun 2018 23:46:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529390772; cv=none; d=google.com; s=arc-20160816; b=NaVhr2opcvFh9h722vp3YXbGm25cIZsa/cLiv1Zbf+3AUFrgX3NQT8a1sAIbek47eT Q5qkODBByQ9HCRirB37s+hxcqzSZQkkb1N3BFkoKSI/LzB6xlU/QeNZlw7Gh2/6oYK8n CQn6SPflBHMgZzLPWdODnqMJ8Gvd9pD7s8kO5YuARXaKekIsr+sN70nKuajG02XSQ+7W nB0itBfNyCrPCSJDNd8cQvJb2EOHBuAcZWurBupD2NBxadcuuwnZa9R+fqc4znIZ87D1 X98qw1RG0NgLV9yBRuip+3QLNTbR4dzzcbc5+rpi9WS5nAYZfl1CM7lYyEeXkINdmg47 K1Yg== 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=Pz/8CC8YBSFoejKCIh8QPg8R9nqbiIkn1Y//vL6VGqY=; b=vI033N3LgFr89AvDwTA3FmuR2LbZ/0YGVedlQIrbaySxGP6LQITIXExYD26XT28suk pa/MgHDMUIpBjShrMuUIyfNLIs9ArR0wZ8Zj+KnHp64b6bgBR3uiBkvYClDs3KrzKBtK dG6BcLYvHpVrQokH2hhkEcAkdghmtfiqwDeauz9NRB58X7YmXu3AurNphRxSLVDbdtTB +3v12DoOfTjTeqtiBihYp5+g6niIMul4JIkBID8T8maNThOS1L++ugdjOPQg2Vp/Sezf 8idwBcgvF7luP7A9KbkViUrAO8CbiCRzX7asddSFsbrdewPaSnq7vVqz5oURKwg3azag 2E6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=XmDJlI5c; 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 x32-v6si16632276pld.435.2018.06.18.23.46.12; Mon, 18 Jun 2018 23:46:12 -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=XmDJlI5c; 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 S1755989AbeFSGqK (ORCPT + 30 others); Tue, 19 Jun 2018 02:46:10 -0400 Received: from mail-pl0-f67.google.com ([209.85.160.67]:45943 "EHLO mail-pl0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755207AbeFSGoH (ORCPT ); Tue, 19 Jun 2018 02:44:07 -0400 Received: by mail-pl0-f67.google.com with SMTP id c23-v6so10390266plz.12 for ; Mon, 18 Jun 2018 23:44:07 -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=Pz/8CC8YBSFoejKCIh8QPg8R9nqbiIkn1Y//vL6VGqY=; b=XmDJlI5cpt8Jvehh2vBfePFAiOA2rGtp7BY6xp3/cmIcbjfogDbdmJvQ2favs88yeC RG+/WubooC+BoY0l966+1IOBdZryN8GKoW5a9OHStmsivB/EFiCRz9kdTzFGxvgwvta8 tC3V5Xp4QMGNWNYPLsJdnsCvTwQIcYgDpF+1M= 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=Pz/8CC8YBSFoejKCIh8QPg8R9nqbiIkn1Y//vL6VGqY=; b=d+sH6uwSt90LGS8xmnkQA6ZZrB6WkPi7R8JOgnv4rG76R+zC516nnMEO8J/l9ri0JH TSGyCHHnQHVcsffMW2ZoDq1jQDKiLT4u1KVe4QEPH9ub5J2t3ZDecBh9xBUoV0lSfhtN qkKiXOgitbLWClWprOpAmTQRUqGG5UFXtQaXvghpcBFeZGHV1XqIuIv4TV+FvizD4FBm lxk/P3Gg8ldJ1WT/YfT0OxhuElhEqsJmXO8zSwEnVXrFIhQLdT1/ow+5oQbmD6Aavymj U32PRZn7BeKdHydo2BdnnMu6OlrclguhWJL3Y5+DRAsN3Pn+ESD5LzJbY8/RUeMryn/B GM5A== X-Gm-Message-State: APt69E3Xs6DBT/5MAhJbQBfmmbNxx8LFT07n0CX01MxAJDrb9P1eumsj l1uUXpCkKsTDsUof26yPrw6R1A== X-Received: by 2002:a17:902:bb81:: with SMTP id m1-v6mr17437964pls.117.1529390647314; Mon, 18 Jun 2018 23:44:07 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id 10-v6sm38423943pfs.111.2018.06.18.23.44.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jun 2018 23:44:06 -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 v2 1/4] arm64: export memblock_reserve()d regions via /proc/iomem Date: Tue, 19 Jun 2018 15:44:21 +0900 Message-Id: <20180619064424.6642-2-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180619064424.6642-1-takahiro.akashi@linaro.org> References: <20180619064424.6642-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 Reviewed-by: Ard Biesheuvel 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 Tue Jun 19 06:44: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: 139089 Delivered-To: patch@linaro.org Received: by 2002:a2e:970d:0:0:0:0:0 with SMTP id r13-v6csp4837549lji; Mon, 18 Jun 2018 23:46:28 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLoboEgYY6vXTwb2fXPhbia/IWDT4cefYfw4mvQXDRoH02R2R8rZfiGTEQqSclk1Cp0AVDZ X-Received: by 2002:a62:4141:: with SMTP id o62-v6mr16578604pfa.111.1529390788777; Mon, 18 Jun 2018 23:46:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529390788; cv=none; d=google.com; s=arc-20160816; b=YvslMC5Dj9QHRrMA8SqoGbyVEvve6pjuNmaZWjwb/nTf7Bfqxql5tOCVTQwD8A2yzf f4HWpL7WMg3QFP8yXujiJV5i0M2zrNA0sBPG5l1JV6vkyHlRJz3z76uZLboLsSmGldcE 7eXt/B7TukcSUb32uqe0JVBtij+l5I/JhbrYxYne/iR7BSkimdYDvgvbBRWYVcHduJR+ fhPslZSVwA5sMRy5xAb+2EO033gUxBXyO71BTWggeQ3cnd7zo5SMGWv8I/66IpebqpO6 +4qYgHuS+546WXS5n7/VXW9rFczXFaOFmC6iMBi//gFctB596Doc21HvfrorSxky8wNA Dn+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=oQBxjbhd3sorzsMaJwszGFfBNGkMSm+1QnH1URdsLGE=; b=athW75heKDH1Dcxi+KvZ5qLBrO+uvsMzfzti+GttgSVpYrAlalFBg210jXWVsRtwMK IZheBn2C9djb2G1aqhd7vQckrW0+lxeyUmAzfvWp6QxRLkA4Lo+MPG6RiSGWdLEmbyYR uuoEkOJhNjdRs2a5x+OLrBLxFVrlnwVvF3IT5jRsBJBUSvFEfZLgFPtY0pWNC8GH1u9J g+S+hPBU/Ay20/yZ6Z+mJHaKm+tcJ16aVqnz2RQP9sXMQK0UUykTofDAaxhrQlM6WpPL EqZeUUpQPXQNRz7Ei83CvhP2pBXf1HsgcZid/bOWJNk2lEfNwO88siVUz59UetYMHE52 2SdQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=bsGImkMY; 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 x32-v6si16632276pld.435.2018.06.18.23.46.28; Mon, 18 Jun 2018 23:46:28 -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=bsGImkMY; 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 S1756229AbeFSGq1 (ORCPT + 30 others); Tue, 19 Jun 2018 02:46:27 -0400 Received: from mail-pl0-f67.google.com ([209.85.160.67]:40831 "EHLO mail-pl0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755536AbeFSGoM (ORCPT ); Tue, 19 Jun 2018 02:44:12 -0400 Received: by mail-pl0-f67.google.com with SMTP id t12-v6so10397328plo.7 for ; Mon, 18 Jun 2018 23:44:12 -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=oQBxjbhd3sorzsMaJwszGFfBNGkMSm+1QnH1URdsLGE=; b=bsGImkMY0YQk+qC/DMf4ZWW82ZNqGj0m/RmAzznQP/SqxLo85JmXW+bGukd2Py81mJ NJq3/y/OrRE5BiufK0c/G2RWf8xbPV9V6YA0PhvhThoHNkqfu8T/kcMV7haRHqLOpUqT Myn7Mo6OWE/tHptsgB9uMtXPrFh6U2gPNvu2o= 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=oQBxjbhd3sorzsMaJwszGFfBNGkMSm+1QnH1URdsLGE=; b=UFjzp/1ykkhFlNu+8YuKTsz870Cuau+jaqaGSPFy+vp+wYN+dArtM+aEJkROQd2MEL 12PI1cJ5JRSyjQh+NAJnk+l/uThhPoe5hpms4OzZLvN2YizoxugiNDVDPTB3XqiuZsRN nmR2GdKZXands9CvV0zX1pEFYiRJBQZybYbaEh9JbGZ39JnDR3KQ3uLl1p1QuvBPapV9 YkbDavN+Knkytcxx5NYItQKyUwLdNZ7eryfekkVe8kZZvfocEIMst8rEGXbh+b9uTyc2 0aoV1So5piR7jf4Tdla77B0v0aF7cCjSG0EtvUnHrdnewQEI3CqmggOQgLmgFPoehhtf gaMQ== X-Gm-Message-State: APt69E0lRIPWh8I1bznAQDByRBv2KKLoSfFBrOrusnWBlqZLlyjbfESN 1KsNK4vYNgL91dJ7sA7arhCiNQ== X-Received: by 2002:a17:902:1e4:: with SMTP id b91-v6mr17386973plb.155.1529390651996; Mon, 18 Jun 2018 23:44:11 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id e68-v6sm32031601pfl.65.2018.06.18.23.44.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jun 2018 23:44:11 -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 v2 2/4] efi/arm: map UEFI memory map even w/o runtime services enabled Date: Tue, 19 Jun 2018 15:44:22 +0900 Message-Id: <20180619064424.6642-3-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180619064424.6642-1-takahiro.akashi@linaro.org> References: <20180619064424.6642-1-takahiro.akashi@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Under the current implementation, UEFI memory map will be mapped and made available in virtual mappings only if runtime services are enabled. But in a later patch, we want to use UEFI memory map in acpi_os_ioremap() to create mappings of ACPI tables using memory attributes described in UEFI memory map. So, as a first step, arm_enter_runtime_services() will be modified so that UEFI memory map will be always accessible. See a relevant commit: arm64: acpi: fix alignment fault in accessing ACPI tables Signed-off-by: AKASHI Takahiro Cc: Ard Biesheuvel --- drivers/firmware/efi/arm-runtime.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) -- 2.17.0 Acked-by: James Morse Reviewed-by: Ard Biesheuvel diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c index 5889cbea60b8..30ac5c82051e 100644 --- a/drivers/firmware/efi/arm-runtime.c +++ b/drivers/firmware/efi/arm-runtime.c @@ -115,6 +115,13 @@ static int __init arm_enable_runtime_services(void) return 0; } + 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 0; + } + if (efi_runtime_disabled()) { pr_info("EFI runtime services will be disabled.\n"); return 0; @@ -127,13 +134,6 @@ static int __init arm_enable_runtime_services(void) 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; From patchwork Tue Jun 19 06:44: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: 139090 Delivered-To: patch@linaro.org Received: by 2002:a2e:970d:0:0:0:0:0 with SMTP id r13-v6csp4837716lji; Mon, 18 Jun 2018 23:46:38 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLk0KqH8FNx8XZfd27sT+w4NwMW55QGrohKYpIpqod72TKORaKiF/Kau74i+xcrw55s1339 X-Received: by 2002:a65:5b8b:: with SMTP id i11-v6mr13704940pgr.225.1529390798840; Mon, 18 Jun 2018 23:46:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529390798; cv=none; d=google.com; s=arc-20160816; b=loa/pZ0C31ra2cDu25QFJZR5T4dLzK9RH4/2N+bS9Glk734hZEqfUm9AYNGJtE/bzt heh8SICuzVAUx0Gjkn2g/L0ecKEs+HDP27fPxTlctZs9B1/cGOuyrDUturmtpSBSYdAE um1KDOlsmZzlddU7P6yhmoqpj676ErkPiL0Vmavk6C8h6LD6PYxxpdgH/IoGNtTh4psc a5diNDjaE95EGWs8L1wScd+xiFvjwR+LgrvwKJYj+5cKf5YWCuFzbbDmdRpHh/0JyseL hhBlzEW1BJYiBPUwA9hpJ+Y7se8onUAskREq+cSFgp9/8xAMcwAbb9QJGY33uzkO9V+a qwLg== 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=4JA6eFkAcHnZdVX+KGJS4BsoGkUY10529cl+HxpjAI8=; b=eN4xwGWHs/u/0/fHelMPhb0CfDRAtYc+XNEbCKXN4evx83yX+mmINzF98SyTKVTUWl uYN+HVxcM5NrczyFAMZHwxlNFG1h9iz7Gm1aziCthaxzYagXP6g45YtCV/muI9het4RJ NXQ7O7uxCswe88eScSOvex5XXl+XjqSaGud5Op79s13BwZfKLqsDM0bO56fGrLUAh3Ne iy88Pun3bYQsCgbgqLKzMG9Vp2gLy3rmINqZXI/H1CdQ1RmGOnhY9lkh2xHod3YPEZ/5 x6Ug/Uq+U/6nfr9o0/yboJUlT3VKAxjP39BnkmxxWWIFA1rBWnec7OoOzY99IJC819Hx zRPA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=CAlTxUKE; 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 x32-v6si16632276pld.435.2018.06.18.23.46.38; Mon, 18 Jun 2018 23:46:38 -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=CAlTxUKE; 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 S1756168AbeFSGqY (ORCPT + 30 others); Tue, 19 Jun 2018 02:46:24 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:38452 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755546AbeFSGoQ (ORCPT ); Tue, 19 Jun 2018 02:44:16 -0400 Received: by mail-pf0-f193.google.com with SMTP id b74-v6so9426125pfl.5 for ; Mon, 18 Jun 2018 23:44:16 -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=4JA6eFkAcHnZdVX+KGJS4BsoGkUY10529cl+HxpjAI8=; b=CAlTxUKEW8gWmVi9b4La27J3km0ZG/CnGJyzaFuTN9MjJRuSQMpUjNGh7Q7aSFEPpC qB6OyHmF2gI23HUg6qsFgBQglrnzCsexaX27Kb+dkYtYHPX/a4scwQs4/zgiYpT9RaKb jcBRW4E5KytRIQf9l5jMdUeIXLbYktQkpjgzw= 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=4JA6eFkAcHnZdVX+KGJS4BsoGkUY10529cl+HxpjAI8=; b=ntPeeQF1/+1rwIg7Sskkk40uyIfUt6OtvHxr/3h/Eil7GD0P/sToZDOasobtPI9IcI owfp5rio0eHvekUTL2ZN0illkYdOAZRgTyHqOONe1pm0gMwe15Sr2umUKOYPj7RvkQG6 NA3SpVcQe2hyHOZjdmjCKHAD4+fOdk2i5wHMEnZGB4BBezkF/TwCnVjH8/1sLkbtS6oX +l6er9ZV4WNhU+glUzwTTi7OMYz6ytfnF0FYPrO4g+vkeHERez/+gU4ZQT6BUfcns5f/ 5M/z/vU3XKIy/O6+fPAMPyI5cvs9+t+RWDYvFr1KVrIDUl1AlxKdojfgDUHb0TS86mwo hfpQ== X-Gm-Message-State: APt69E0f8ftCyLYAPitdUAPzQEXNQBDj5MmUimq+bM8/bPZosGOm2oSo YSltMxSqhode+B4Fu0Q/RL23bg== X-Received: by 2002:a63:a44a:: with SMTP id c10-v6mr13488189pgp.198.1529390656084; Mon, 18 Jun 2018 23:44:16 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id 67-v6sm33800825pfm.171.2018.06.18.23.44.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jun 2018 23:44:15 -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 v2 3/4] efi/arm: map UEFI memory map earlier on boot Date: Tue, 19 Jun 2018 15:44:23 +0900 Message-Id: <20180619064424.6642-4-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180619064424.6642-1-takahiro.akashi@linaro.org> References: <20180619064424.6642-1-takahiro.akashi@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Since arm_enter_runtime_services() was modified to always create a virtual mapping of UEFI memory map in the previous patch, it is now renamed to efi_enter_virtual_mode() and called earlier before acpi_load_tables() in acpi_early_init(). This will allow us to use UEFI memory map in acpi_os_ioremap() to create mappings of ACPI tables using memory attributes described in UEFI memory map. See a relevant commit: arm64: acpi: fix alignment fault in accessing ACPI tables Signed-off-by: AKASHI Takahiro Cc: Ard Biesheuvel Cc: Andrew Morton --- drivers/firmware/efi/arm-runtime.c | 15 ++++++--------- init/main.c | 3 +++ 2 files changed, 9 insertions(+), 9 deletions(-) -- 2.17.0 diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c index 30ac5c82051e..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 0; + 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"); 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) { 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(); From patchwork Tue Jun 19 06:44:24 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 139091 Delivered-To: patch@linaro.org Received: by 2002:a2e:970d:0:0:0:0:0 with SMTP id r13-v6csp4837855lji; Mon, 18 Jun 2018 23:46:49 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIRQfg5n15A91+2bP87w1fqfY3YwCwmQfbOJSaFggBGTKpJwJjOlIly5C9TxAlrJp2MZaVi X-Received: by 2002:a63:3807:: with SMTP id f7-v6mr13762847pga.446.1529390809477; Mon, 18 Jun 2018 23:46:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529390809; cv=none; d=google.com; s=arc-20160816; b=PKUuPa4BJkT5g7p6zx5WAtOeE3fFwI+JQm9dzvWk7ByeqC4AI64Ge8wfdUtzB7fDig nV/+pIoJN06deVAKDP8AcjO2bbVlUxIdZiy4KOQJ8VoQkmvpHGzW9kbvO1vUmdvNK4PG IFL61aRggOQJ/nwT9ZM0t5Tq5hy1cy7obgk6r2n5qbrNCCxHvqheJaSYA5yujyTFUZqA VwDPv5Djjz7avXN/uSz2LRcegh8Ffn/661TulLchA24ToIkMR7++TojQaOv2nAbIrKf6 tjAT+YgJygwZoXWvof3iAKCMZP1pev2iGfZ4SAftQXkmtsIXtc+ScGcJXqvXKbkq+xZ3 X0pA== 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=U5jmUh0cvS7hoqJAsRrWRzTdfHnP4v9CDis62qBU8Q4=; b=i75cYZBUCfMqf9sDfsSOm25acnyRHw6FTaqgku5gPyE7Qm9Cmd4GlZeE1oS/VMsyVS Qpt+MIEDOYRSbmjqWxO+HmbA3qyq23qrWml8+ewnQp5+IGsLgyDXIVSk+sBZqN/JKMrj UsMMVP+sQqSgLzu0P7hSBv1N5bTEeydV2qUh43UBK0Oa58jx5feIZ4wyVvztKN93O6qv N2BGXlId5d0+IOxe/faziHkPZ5OIegGT3AZHFH6C3O9aPuYVPePXJITz96HtVgSv3HvE 8vgpCkRzgP9sH8v5kWZ92vUy0ZN9jWXjlFHRKGM1IePcwmo6mvtVaoIMu4QOWWG3fK6+ Sg6A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Ok9AH5f6; 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 x32-v6si16632276pld.435.2018.06.18.23.46.49; Mon, 18 Jun 2018 23:46:49 -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=Ok9AH5f6; 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 S1756117AbeFSGqX (ORCPT + 30 others); Tue, 19 Jun 2018 02:46:23 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:44444 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755553AbeFSGoU (ORCPT ); Tue, 19 Jun 2018 02:44:20 -0400 Received: by mail-pf0-f194.google.com with SMTP id h12-v6so9424967pfk.11 for ; Mon, 18 Jun 2018 23:44: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=U5jmUh0cvS7hoqJAsRrWRzTdfHnP4v9CDis62qBU8Q4=; b=Ok9AH5f63Z5P4nLp4R86Cbrme3ylXGTziiRhMeWfAfpPvZsvjHvNmdfovMFBW4Kz4K 7+++RgkEKLM/N4q+KBmciZjxPBGWbXK61CHVGyCHqJVZ7fzGw5T5LuT5i+3TRjPfEgD3 RZNR8ZiIC2kxfN5DmmHRDMDjV1jfSBW2H3mew= 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=U5jmUh0cvS7hoqJAsRrWRzTdfHnP4v9CDis62qBU8Q4=; b=nUn0W5nQWRbOD1jMkPqax0T9W5VkGKMkki96vOyhae765zq1fwHReBf4ObJo8wqwTs YimoRyn8n7dTuFkHMIew9qZ5iyATnVXv24zNNjyJeqWjzeP+3+rd6uH6qUM761hlE3zy KxNxzkuIQfrtXG7bbnS2DpX86kz1s9HkuNHGNMIi51I1N/vvi+sYs+KSyeetz659HV// k+xvWoU6YXGru8kEz2MWnYxePwYW4n4GgvrcYv9RePc9G2K0hu6w6aAZC2Xd1rJtQkE+ /ERHCpu6tNAFblfKkdm+xuv6v2eDvrUB0xWY1Mn03Xw1HE1ruAeFa5jtkICM/leXN27F pmNg== X-Gm-Message-State: APt69E3gXoJrTUQf3qzWqSsRHreIlpyvOwlJw+4T09SwniKDOzBQpsQf VCuswmzgGtkru2LPamtQio33rg== X-Received: by 2002:a65:508d:: with SMTP id r13-v6mr13893264pgp.143.1529390660231; Mon, 18 Jun 2018 23:44:20 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id i71-v6sm23289450pgd.22.2018.06.18.23.44.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jun 2018 23:44: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, AKASHI Takahiro Subject: [PATCH v2 4/4] arm64: acpi: fix alignment fault in accessing ACPI Date: Tue, 19 Jun 2018 15:44:24 +0900 Message-Id: <20180619064424.6642-5-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180619064424.6642-1-takahiro.akashi@linaro.org> References: <20180619064424.6642-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. Signed-off-by: AKASHI Takahiro Suggested-by: James Morse Suggested-by: Ard Biesheuvel Reported-by and Tested-by: Bhupesh Sharma --- arch/arm64/include/asm/acpi.h | 23 ++++++++++++++++------- arch/arm64/kernel/acpi.c | 11 +++-------- 2 files changed, 19 insertions(+), 15 deletions(-) -- 2.17.0 Reviewed-by: James Morse Reviewed-by: Ard Biesheuvel diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h index 0db62a4cbce2..68bc18cb2b85 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 @@ -129,7 +135,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