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.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,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 777D7C2BA19 for ; Tue, 14 Apr 2020 17:21:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3BC5A20678 for ; Tue, 14 Apr 2020 17:21:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3BC5A20678 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 BB9188E002C; Tue, 14 Apr 2020 13:21:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B691C8E0001; Tue, 14 Apr 2020 13:21:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A30B98E002C; Tue, 14 Apr 2020 13:21:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0070.hostedemail.com [216.40.44.70]) by kanga.kvack.org (Postfix) with ESMTP id 86B898E0001 for ; Tue, 14 Apr 2020 13:21:21 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 4BFC2180AD807 for ; Tue, 14 Apr 2020 17:21:21 +0000 (UTC) X-FDA: 76707126762.14.paint08_802fd29031053 X-HE-Tag: paint08_802fd29031053 X-Filterd-Recvd-Size: 3871 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Tue, 14 Apr 2020 17:21:20 +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 DA7A730E; Tue, 14 Apr 2020 10:21:19 -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 3B9183F6C4; Tue, 14 Apr 2020 10:21:18 -0700 (PDT) Subject: Re: [PATCH 2/3] mm/memory_hotplug: Allow arch override of non boot memory resource names To: piliu Cc: Dave Young , kexec@lists.infradead.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, Anshuman Khandual , Catalin Marinas , Bhupesh Sharma , Eric Biederman , Andrew Morton , Will Deacon , Hari Bathini References: <20200326180730.4754-1-james.morse@arm.com> <20200326180730.4754-3-james.morse@arm.com> <20200402054946.GA97238@dhcp-128-65.nay.redhat.com> <9725d779-e0de-2d8d-8716-22df3e791820@redhat.com> From: James Morse Message-ID: <66b0cb1a-d63a-2720-19cf-3d8efcd02fde@arm.com> Date: Tue, 14 Apr 2020 18:21:16 +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: <9725d779-e0de-2d8d-8716-22df3e791820@redhat.com> Content-Type: text/plain; charset=windows-1252 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 Dave, Pingfan, On 02/04/2020 07:12, piliu wrote: > On 04/02/2020 01:49 PM, Dave Young wrote: >> On 03/26/20 at 06:07pm, James Morse wrote: >>> 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. >> >> Could arm64 use similar way to update DT, or a cooked UEFI maps? >> Add pingfan in cc, he said ppc64 update the DT after a memremove thus it >> would be good to just redo a kexec load. > Yes, the memory changes will be observed through device-node under > /proc/device-tree/ (which is for powerpc). > > Later if running kexec -l/-p , it can build new dtb with the latest info > from /proc/device-tree For arm64, the device-tree is set in stone. We don't have the runtime parts of open-firmware that powerpc does. (my knowledge in this area is extremely sparse) arm64 platforms where stuff like this changes tend to use ACPI instead, and these all have to boot with UEFI, which means its the UEFI memory map that has authority. We don't cook a fake UEFI memory map when things change because we treat it like the set-in-stone DT. This means we only have discrepancies in firmware to workaround, instead of any we introduce ourselves. One of the UEFI configuration tables describes addresses Linux programmed into hardware that can't be reset. Newer versions of Linux know how to pick these up on kexec... but older versions don't know how to parse/rewrite/move that table. Cooking up new versions of these tables would prevent us doing stuff like this, which we need to workaround hardware that didn't get the 'kexec exists' memo. Thanks, James