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 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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 A0C75C55185 for ; Wed, 22 Apr 2020 12:14:45 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6ED282084D for ; Wed, 22 Apr 2020 12:14:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="RUfzF7rY" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6ED282084D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=SzbKC3uqAXrzYBKI5+yRkrICe6AU9W5+nYNzcnjiveA=; b=RUfzF7rYMyMNMD QMFz6y+76kptS5ZEXNzPNbnAJj5vN/bIgzQopkQ7n7f0mdfEllXmtbJoSq+02sGdOrjbdyR5uqGxy e5YKV6TrP4QCkAnvQ3YY8wr0vJG0N744FSXiPkBpr2ypWtfbdDcjFiK0Kt2Rhs1sxH5htLUvfpe71 lzos42CsAdZEwAPg9EypezxmwVjOZdRmkKSBXSa/lzY3GNa6UePBqkcVu6Y2cQ553SNhU+qxdxv3g AjXNWw7lCvaJKQ1Gh3Z0CXizm8f00efqc7+GtklaQDdZk3x/FfE5cdnGfXnXx671kgmQ8vnNOsknd ie1nFyAm2hbR+RYBJrTQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jREH3-0006Hh-KI; Wed, 22 Apr 2020 12:14:41 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jREGm-00062t-Vl; Wed, 22 Apr 2020 12:14:26 +0000 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" 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-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200422_051425_096256_E9E6B809 X-CRM114-Status: GOOD ( 13.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Anshuman Khandual , Catalin Marinas , Bhupesh Sharma , kexec@lists.infradead.org, linux-mm@kvack.org, Andrew Morton , Will Deacon , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Subject: Re: [PATCH 2/3] mm/memory_hotplug: Allow arch override of non boot memory resource names 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 MIME-Version: 1.0 In-Reply-To: <873694h4g3.fsf@x220.int.ebiederm.org> Content-Language: en-GB List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: "Eric W. Biederman" Cc: Anshuman Khandual , Catalin Marinas , Bhupesh Sharma , kexec@lists.infradead.org, linux-mm@kvack.org, Andrew Morton , Will Deacon , linux-arm-kernel@lists.infradead.org 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 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec