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=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 03861C43331 for ; Mon, 30 Mar 2020 17:17:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C1A2020776 for ; Mon, 30 Mar 2020 17:17:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C1A2020776 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 4F9E36B0037; Mon, 30 Mar 2020 13:17:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4A9776B006C; Mon, 30 Mar 2020 13:17:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E6896B006E; Mon, 30 Mar 2020 13:17:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0041.hostedemail.com [216.40.44.41]) by kanga.kvack.org (Postfix) with ESMTP id 1CB606B0037 for ; Mon, 30 Mar 2020 13:17:38 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 883DE181AD0A2 for ; Mon, 30 Mar 2020 17:17:37 +0000 (UTC) X-FDA: 76652685354.07.car88_5fa04b7fe1e60 X-HE-Tag: car88_5fa04b7fe1e60 X-Filterd-Recvd-Size: 4974 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Mon, 30 Mar 2020 17:17:36 +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 C8DB1113E; Mon, 30 Mar 2020 10:17:35 -0700 (PDT) Received: from [172.16.1.108] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BF5AE3F68F; Mon, 30 Mar 2020 10:17:33 -0700 (PDT) Subject: Re: [PATCH 2/3] mm/memory_hotplug: Allow arch override of non boot memory resource names To: David Hildenbrand Cc: kexec@lists.infradead.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, Eric Biederman , Andrew Morton , Catalin Marinas , Will Deacon , Anshuman Khandual , Bhupesh Sharma , Vitaly Kuznetsov References: <20200326180730.4754-1-james.morse@arm.com> <20200326180730.4754-3-james.morse@arm.com> <52d6fd33-c15d-b842-84ed-b4a74265199f@redhat.com> <25aa3f43-5aa9-653f-0910-dd7b75527e08@arm.com> <1090cc16-fa6b-8dd2-8c41-22136f733f00@redhat.com> From: James Morse Openpgp: preference=signencrypt Message-ID: Date: Mon, 30 Mar 2020 18:17:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <1090cc16-fa6b-8dd2-8c41-22136f733f00@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US 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 David, On 3/30/20 2:23 PM, David Hildenbrand wrote: >>>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c >>>> index 0a54ffac8c68..69b03dd7fc74 100644 >>>> --- a/mm/memory_hotplug.c >>>> +++ b/mm/memory_hotplug.c >>>> @@ -42,6 +42,10 @@ >>>> #include "internal.h" >>>> #include "shuffle.h" >>>> >>>> +#ifndef MEMORY_HOTPLUG_RES_NAME >>>> +#define MEMORY_HOTPLUG_RES_NAME "System RAM" >>>> +#endif >>> >>> So I assume changing this for all architectures would result in some >>> user space tool breaking? Are we aware of any? >> >> Last time we had to touch arm64's /proc/iomem strings I went through debian's >> codesearch for stuff that reads it, kexec-tools was the only thing that parsed >> it in anger. (From memory, the other tools were looking for PCIe windows to do >> firmware flashing..) >> >> Looking again, having qualifiers on the end of 'System RAM' looks like it could >> confuse 's390-tools's detect_mem_chunks parser. > > Good to know, we should find out if this could work. > >> >> It looks like the strings that come out of 'FIRMWARE_MEMMAP' are a duplicate set. >> >> >>> I do wonder if we should simply change it for all architectures if possible. >> >> If its possible that would be great. But I suspect that ship has sailed, >> changing it on other architectures could break some fragile parsing code. > > I assume any parser has to be prepared for new types showing up. > Otherwise these would not be future proof. The question is if a common > prefix is problematic. > > E.g., Use "Hotplugged System RAM" instead of "System RAM (hotplug)" Aha, I went for a (suffix) because that is what 32bit Arm did for the boot alias. >> I'm wary of changing it on arm64, the only thing that makes it tolerable is that >> memory hot-add was relatively recently merged, and we don't anticipate it being >> widely used until you can remove memory as well. >> >> Changing it on arm64 is to prevent today's versions of kexec-tools from >> accidentally placing the new kernel in memory that wasn't described at boot. >> This leads to an unhandled exception during boot[0] because the kernel can't >> access itself via the mapping of all memory. (hotpluggable regions are only >> discovered by suitably configured ACPI systems much later) > I want the very same for virtio-mem (initially x86-only, but later open > for all archs). Can also be interesting for Hyper-V. kexec should not > try to use hotplugged memory as kexec target, as memory blocks can be > partially inaccessible. Great! I assumed these placement requirements would be arm64 specific. > Of course, I can provide an interface to override the name via > add_memory(), but having it on all architectures handled in a similar > way right from the start would be nicer. I agree having it the same on all architectures would be good. It sounds like virtio-mem is a better argument for doing this than arm64's firmware memory description. I'll have a read, and maybe post something to linux-arch to do this at rc1. (I assume we'll have a few weeks to make sure arm64 at least uses the same name if it goes on longer) 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=-5.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 74C68C2D0EB for ; Mon, 30 Mar 2020 17:17:58 +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 3732120578 for ; Mon, 30 Mar 2020 17:17:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="N/zSyLpy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3732120578 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=EdUXJwm3vUZaFgEu0BKgnsOM8b7DpyVZB1bgX9w4jt4=; b=N/zSyLpyGbIx39 o/buyX0d408iTRDmH4wQT1m62LZNHjQAIK4PIfFUOT3piOlAGVT1eXhk/+bEeR7lD26grWijdQn8E z8V55t5JT8X55qNcAQVrnZJtsZWZqPBW1hWWDLcF8FzbgtEpVQgDPc58IJOavhLkjzm6675mpN6W3 OnRLbqwO2ISiD/cJ27ZtbrRF+winY+vqUTlmZ+GoimS0Zesjw4BHCVXU+d+0ymFoONBnyH6CBOa5M S6qJlojx8g1FhQcoL0fJK3T2QKkF8bCR991iP9FcqYWhsFCC/iKKBP+TdhyS8UMkZdNskSoybvraJ k4p6qr8rjlH0uxMkgkaQ==; 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 1jIy2s-0003oe-8k; Mon, 30 Mar 2020 17:17:54 +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 1jIy2a-0003Yo-As; Mon, 30 Mar 2020 17:17:38 +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 C8DB1113E; Mon, 30 Mar 2020 10:17:35 -0700 (PDT) Received: from [172.16.1.108] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BF5AE3F68F; Mon, 30 Mar 2020 10:17:33 -0700 (PDT) Subject: Re: [PATCH 2/3] mm/memory_hotplug: Allow arch override of non boot memory resource names To: David Hildenbrand References: <20200326180730.4754-1-james.morse@arm.com> <20200326180730.4754-3-james.morse@arm.com> <52d6fd33-c15d-b842-84ed-b4a74265199f@redhat.com> <25aa3f43-5aa9-653f-0910-dd7b75527e08@arm.com> <1090cc16-fa6b-8dd2-8c41-22136f733f00@redhat.com> From: James Morse Openpgp: preference=signencrypt Message-ID: Date: Mon, 30 Mar 2020 18:17:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <1090cc16-fa6b-8dd2-8c41-22136f733f00@redhat.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200330_101736_489617_41BACE6E X-CRM114-Status: GOOD ( 20.42 ) 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, Eric Biederman , Andrew Morton , Will Deacon , Vitaly Kuznetsov , 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 David, On 3/30/20 2:23 PM, David Hildenbrand wrote: >>>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c >>>> index 0a54ffac8c68..69b03dd7fc74 100644 >>>> --- a/mm/memory_hotplug.c >>>> +++ b/mm/memory_hotplug.c >>>> @@ -42,6 +42,10 @@ >>>> #include "internal.h" >>>> #include "shuffle.h" >>>> >>>> +#ifndef MEMORY_HOTPLUG_RES_NAME >>>> +#define MEMORY_HOTPLUG_RES_NAME "System RAM" >>>> +#endif >>> >>> So I assume changing this for all architectures would result in some >>> user space tool breaking? Are we aware of any? >> >> Last time we had to touch arm64's /proc/iomem strings I went through debian's >> codesearch for stuff that reads it, kexec-tools was the only thing that parsed >> it in anger. (From memory, the other tools were looking for PCIe windows to do >> firmware flashing..) >> >> Looking again, having qualifiers on the end of 'System RAM' looks like it could >> confuse 's390-tools's detect_mem_chunks parser. > > Good to know, we should find out if this could work. > >> >> It looks like the strings that come out of 'FIRMWARE_MEMMAP' are a duplicate set. >> >> >>> I do wonder if we should simply change it for all architectures if possible. >> >> If its possible that would be great. But I suspect that ship has sailed, >> changing it on other architectures could break some fragile parsing code. > > I assume any parser has to be prepared for new types showing up. > Otherwise these would not be future proof. The question is if a common > prefix is problematic. > > E.g., Use "Hotplugged System RAM" instead of "System RAM (hotplug)" Aha, I went for a (suffix) because that is what 32bit Arm did for the boot alias. >> I'm wary of changing it on arm64, the only thing that makes it tolerable is that >> memory hot-add was relatively recently merged, and we don't anticipate it being >> widely used until you can remove memory as well. >> >> Changing it on arm64 is to prevent today's versions of kexec-tools from >> accidentally placing the new kernel in memory that wasn't described at boot. >> This leads to an unhandled exception during boot[0] because the kernel can't >> access itself via the mapping of all memory. (hotpluggable regions are only >> discovered by suitably configured ACPI systems much later) > I want the very same for virtio-mem (initially x86-only, but later open > for all archs). Can also be interesting for Hyper-V. kexec should not > try to use hotplugged memory as kexec target, as memory blocks can be > partially inaccessible. Great! I assumed these placement requirements would be arm64 specific. > Of course, I can provide an interface to override the name via > add_memory(), but having it on all architectures handled in a similar > way right from the start would be nicer. I agree having it the same on all architectures would be good. It sounds like virtio-mem is a better argument for doing this than arm64's firmware memory description. I'll have a read, and maybe post something to linux-arch to do this at rc1. (I assume we'll have a few weeks to make sure arm64 at least uses the same name if it goes on longer) Thanks, James _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel