From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C49F4C55185 for ; Wed, 22 Apr 2020 12:14:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8E69D2087E for ; Wed, 22 Apr 2020 12:14:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8E69D2087E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 25FA58E0014; Wed, 22 Apr 2020 08:14:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 20F438E0003; Wed, 22 Apr 2020 08:14:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D7BB8E0014; Wed, 22 Apr 2020 08:14:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0253.hostedemail.com [216.40.44.253]) by kanga.kvack.org (Postfix) with ESMTP id E689F8E0003 for ; Wed, 22 Apr 2020 08:14:25 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id A4805180AD81F for ; Wed, 22 Apr 2020 12:14:25 +0000 (UTC) X-FDA: 76735383690.18.lake11_60d286575b233 X-HE-Tag: lake11_60d286575b233 X-Filterd-Recvd-Size: 3111 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Wed, 22 Apr 2020 12:14:25 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 208CB1042; Wed, 22 Apr 2020 05:14:24 -0700 (PDT) Received: from [192.168.0.14] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E58AE3F6CF; Wed, 22 Apr 2020 05:14:22 -0700 (PDT) Subject: Re: [PATCH 2/3] mm/memory_hotplug: Allow arch override of non boot memory resource names To: "Eric W. Biederman" Cc: kexec@lists.infradead.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, Anshuman Khandual , Catalin Marinas , Bhupesh Sharma , Andrew Morton , Will Deacon References: <20200326180730.4754-1-james.morse@arm.com> <20200326180730.4754-3-james.morse@arm.com> <873694h4g3.fsf@x220.int.ebiederm.org> From: James Morse Message-ID: Date: Wed, 22 Apr 2020 13:14:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <873694h4g3.fsf@x220.int.ebiederm.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Eric, On 15/04/2020 21:36, Eric W. Biederman wrote: > James Morse writes: > >> Memory added to the system by hotplug has a 'System RAM' resource created >> for it. This is exposed to user-space via /proc/iomem. >> >> This poses problems for kexec on arm64. If kexec decides to place the >> kernel in one of these newly onlined regions, the new kernel will find >> itself booting from a region not described as memory in the firmware >> tables. >> >> Arm64 doesn't have a structure like the e820 memory map that can be >> re-written when memory is brought online. Instead arm64 uses the UEFI >> memory map, or the memory node from the DT, sometimes both. We never >> rewrite these. >> >> Allow an architecture to specify a different name for these hotplug >> regions. > > Gah. No. > > Please find a way to pass the current memory map to the loaded kexec'd > kernel. > Starting a kernel with no way for it to know what the current memory map > is just plain scary. We have one. Firmware tables are the source of all this information. We don't tamper with them. Firmware describes memory present at boot in the UEFI memory map or DT. On systems with ACPI, regions that were added after booting are discovered by running AML methods. (for which we need to allocate memory, so you can't describe boot memory like this) This doesn't work if you kexec from a hot-added region. You've booted from memory that wasn't present at boot. I don't think this is fixable with the set of constraints. Thanks, James