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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 25175C433F5 for ; Fri, 1 Oct 2021 14:03:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EEE2B61278 for ; Fri, 1 Oct 2021 14:03:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353822AbhJAOFG (ORCPT ); Fri, 1 Oct 2021 10:05:06 -0400 Received: from mail.kernel.org ([198.145.29.99]:49366 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231824AbhJAOE7 (ORCPT ); Fri, 1 Oct 2021 10:04:59 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id B184461439; Fri, 1 Oct 2021 14:03:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1633096994; bh=j7RiikMVul/vm+Prmyx1rYn9xETi77NUVt/50phH7k0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JIchVvHkPwXFrApRkJNJ1jo9dQIfHa2T63ZG1i87FhM0l0ZvtL87mlGvplRQBraes vyMIL4dKf6z0JSmVBUSKIGtpiCVW0zfnCqS9jOnbL2dAZNjae538ZVygnqS9nR+eLF xHUU2hdOzmpySeLHR8g8uhJ86dXHlY3KzJVFj48iCHOSsm/sFJxKKMIWTwhwBE82+F FzjRuTX/sl0Oc1bN9a0bDb8maV8TNilTngNHqHbDe+oFp/6kLeNtnncm2EB6xtvQPd RxHjszo7Yuib1/P1V58ChVRmeUZKnKnZO6L+qjCn49PqGMSsJSfKE5Y6LZatW8Cmz/ K9IirY56cVdeg== Date: Fri, 1 Oct 2021 07:03:13 -0700 From: Mike Rapoport To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, Andrew Morton , Michal Hocko , Oscar Salvador , Jianyong Wu , "Aneesh Kumar K . V" , Vineet Gupta , Geert Uytterhoeven , Huacai Chen , Jiaxun Yang , Thomas Bogendoerfer , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Eric Biederman , Arnd Bergmann , linux-snps-arc@lists.infradead.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-s390@vger.kernel.org, linux-mm@kvack.org, kexec@lists.infradead.org Subject: Re: [PATCH v1 3/4] memblock: add MEMBLOCK_DRIVER_MANAGED to mimic IORESOURCE_SYSRAM_DRIVER_MANAGED Message-ID: References: <20210927150518.8607-1-david@redhat.com> <20210927150518.8607-4-david@redhat.com> <830c1670-378b-0fb6-bd5e-208e545fa126@redhat.com> <0d6c86ba-076b-5d4b-33a8-da267f951a85@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0d6c86ba-076b-5d4b-33a8-da267f951a85@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 01, 2021 at 10:04:24AM +0200, David Hildenbrand wrote: > On 30.09.21 23:21, Mike Rapoport wrote: > > On Wed, Sep 29, 2021 at 06:54:01PM +0200, David Hildenbrand wrote: > > > On 29.09.21 18:39, Mike Rapoport wrote: > > > > Hi, > > > > > > > > On Mon, Sep 27, 2021 at 05:05:17PM +0200, David Hildenbrand wrote: > > > > > Let's add a flag that corresponds to IORESOURCE_SYSRAM_DRIVER_MANAGED. > > > > > Similar to MEMBLOCK_HOTPLUG, most infrastructure has to treat such memory > > > > > like ordinary MEMBLOCK_NONE memory -- for example, when selecting memory > > > > > regions to add to the vmcore for dumping in the crashkernel via > > > > > for_each_mem_range(). > > > > Can you please elaborate on the difference in semantics of MEMBLOCK_HOTPLUG > > > > and MEMBLOCK_DRIVER_MANAGED? > > > > Unless I'm missing something they both mark memory that can be unplugged > > > > anytime and so it should not be used in certain cases. Why is there a need > > > > for a new flag? > > > > > > In the cover letter I have "Alternative B: Reuse MEMBLOCK_HOTPLUG. > > > MEMBLOCK_HOTPLUG serves a different purpose, though.", but looking into the > > > details it won't work as is. > > > > > > MEMBLOCK_HOTPLUG is used to mark memory early during boot that can later get > > > hotunplugged again and should be placed into ZONE_MOVABLE if the > > > "movable_node" kernel parameter is set. > > > > > > The confusing part is that we talk about "hotpluggable" but really mean > > > "hotunpluggable": the reason is that HW flags DIMM slots that can later be > > > hotplugged as "hotpluggable" even though there is already something > > > hotplugged. > > > > MEMBLOCK_HOTPLUG name is indeed somewhat confusing, but still it's core > > meaning "this memory may be removed" which does not differ from what > > IORESOURCE_SYSRAM_DRIVER_MANAGED means. > > > > MEMBLOCK_HOTPLUG regions are indeed placed into ZONE_MOVABLE, but more > > importantly, they are avoided when we allocate memory from memblock. > > > > So, in my view, both flags mean that the memory may be removed and it > > should not be used for certain types of allocations. > > The semantics are different: > > MEMBLOCK_HOTPLUG: memory is indicated as "System RAM" in the > firmware-provided memory map and added to the system early during boot; we > want this memory to be managed by ZONE_MOVABLE with "movable_node" set on > the kernel command line, because only then we want it to be hotpluggable > again. kexec *has to* indicate this memory to the second kernel and can > place kexec-images on this memory. After memory hotunplug, kexec has to be > re-armed. > > MEMBLOCK_DRIVER_MANAGED: memory is not indicated as System RAM" in the > firmware-provided memory map; this memory is always detected and added to > the system by a driver; memory might not actually be physically > hotunpluggable and the ZONE selection does not depend on "movable_core". > kexec *must not* indicate this memory to the second kernel and *must not* > place kexec-images on this memory. Ok, this clarifies. This explanation should be a part of the changelog. The sentences about the zone selection could be probably skipped, because they are less important for this case. E.g something like: MEMBLOCK_HOTPLUG: memory is indicated as "System RAM" in the firmware-provided memory map and added to the system early during boot; kexec *has to* indicate this memory to the second kernel and can place kexec-images on this memory. After memory hotunplug, kexec has to be re-armed. MEMBLOCK_DRIVER_MANAGED: memory is not indicated as "System RAM" in the firmware-provided memory map; this memory is always detected and added to the system by a driver; memory might not actually be physically hotunpluggable. kexec *must not* indicate this memory to the second kernel and *must not* place kexec-images on this memory. -- Sincerely yours, Mike. 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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9C380C433EF for ; Fri, 1 Oct 2021 14:03:20 +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 5D310619F9 for ; Fri, 1 Oct 2021 14:03:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5D310619F9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=LdNStMgbw6KzmsK016bmRi1LSg+fg/Cl+Vlsg5P7pUY=; b=nilHnxEnhs3VJE zqtVXSoXlhe97Ki+1fc9TtGDWQhzkl0Y0ZgBi7uiv/IDPVB6G1Lpu62r27Wmoj8PB5Iyz+pH6UH4p UGC+CuPcI8rxr1MK2JqsXqxTrUNGeoUNdcUHC2ocUPj1pnfjeezXuNtP4NE4VOoSEVD05VW/L6+kv UhSFMpMP7dzISbnJKf+H+/Zk9O8LK6rkAiGusY9a/J+/9Q/V0g9Iq3cB0CpDL/QXTeFB+2E+yWypR mfMideFgvfx847wpnHRoMgdZIuSYXNQ70J/qVXPT9MELm9p3Uq23evXlx0Fst7OQrl4oAbPIv9+HE 3lF+0b6AbVaAwZiUt+SQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mWJ8B-000Tdb-UZ; Fri, 01 Oct 2021 14:03:19 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mWJ87-000Tby-Hz; Fri, 01 Oct 2021 14:03:17 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id B184461439; Fri, 1 Oct 2021 14:03:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1633096994; bh=j7RiikMVul/vm+Prmyx1rYn9xETi77NUVt/50phH7k0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JIchVvHkPwXFrApRkJNJ1jo9dQIfHa2T63ZG1i87FhM0l0ZvtL87mlGvplRQBraes vyMIL4dKf6z0JSmVBUSKIGtpiCVW0zfnCqS9jOnbL2dAZNjae538ZVygnqS9nR+eLF xHUU2hdOzmpySeLHR8g8uhJ86dXHlY3KzJVFj48iCHOSsm/sFJxKKMIWTwhwBE82+F FzjRuTX/sl0Oc1bN9a0bDb8maV8TNilTngNHqHbDe+oFp/6kLeNtnncm2EB6xtvQPd RxHjszo7Yuib1/P1V58ChVRmeUZKnKnZO6L+qjCn49PqGMSsJSfKE5Y6LZatW8Cmz/ K9IirY56cVdeg== Date: Fri, 1 Oct 2021 07:03:13 -0700 From: Mike Rapoport To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, Andrew Morton , Michal Hocko , Oscar Salvador , Jianyong Wu , "Aneesh Kumar K . V" , Vineet Gupta , Geert Uytterhoeven , Huacai Chen , Jiaxun Yang , Thomas Bogendoerfer , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Eric Biederman , Arnd Bergmann , linux-snps-arc@lists.infradead.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-s390@vger.kernel.org, linux-mm@kvack.org, kexec@lists.infradead.org Subject: Re: [PATCH v1 3/4] memblock: add MEMBLOCK_DRIVER_MANAGED to mimic IORESOURCE_SYSRAM_DRIVER_MANAGED Message-ID: References: <20210927150518.8607-1-david@redhat.com> <20210927150518.8607-4-david@redhat.com> <830c1670-378b-0fb6-bd5e-208e545fa126@redhat.com> <0d6c86ba-076b-5d4b-33a8-da267f951a85@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0d6c86ba-076b-5d4b-33a8-da267f951a85@redhat.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211001_070315_677561_B7E31FF4 X-CRM114-Status: GOOD ( 37.55 ) X-BeenThere: linux-snps-arc@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux on Synopsys ARC Processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+linux-snps-arc=archiver.kernel.org@lists.infradead.org On Fri, Oct 01, 2021 at 10:04:24AM +0200, David Hildenbrand wrote: > On 30.09.21 23:21, Mike Rapoport wrote: > > On Wed, Sep 29, 2021 at 06:54:01PM +0200, David Hildenbrand wrote: > > > On 29.09.21 18:39, Mike Rapoport wrote: > > > > Hi, > > > > > > > > On Mon, Sep 27, 2021 at 05:05:17PM +0200, David Hildenbrand wrote: > > > > > Let's add a flag that corresponds to IORESOURCE_SYSRAM_DRIVER_MANAGED. > > > > > Similar to MEMBLOCK_HOTPLUG, most infrastructure has to treat such memory > > > > > like ordinary MEMBLOCK_NONE memory -- for example, when selecting memory > > > > > regions to add to the vmcore for dumping in the crashkernel via > > > > > for_each_mem_range(). > > > > Can you please elaborate on the difference in semantics of MEMBLOCK_HOTPLUG > > > > and MEMBLOCK_DRIVER_MANAGED? > > > > Unless I'm missing something they both mark memory that can be unplugged > > > > anytime and so it should not be used in certain cases. Why is there a need > > > > for a new flag? > > > > > > In the cover letter I have "Alternative B: Reuse MEMBLOCK_HOTPLUG. > > > MEMBLOCK_HOTPLUG serves a different purpose, though.", but looking into the > > > details it won't work as is. > > > > > > MEMBLOCK_HOTPLUG is used to mark memory early during boot that can later get > > > hotunplugged again and should be placed into ZONE_MOVABLE if the > > > "movable_node" kernel parameter is set. > > > > > > The confusing part is that we talk about "hotpluggable" but really mean > > > "hotunpluggable": the reason is that HW flags DIMM slots that can later be > > > hotplugged as "hotpluggable" even though there is already something > > > hotplugged. > > > > MEMBLOCK_HOTPLUG name is indeed somewhat confusing, but still it's core > > meaning "this memory may be removed" which does not differ from what > > IORESOURCE_SYSRAM_DRIVER_MANAGED means. > > > > MEMBLOCK_HOTPLUG regions are indeed placed into ZONE_MOVABLE, but more > > importantly, they are avoided when we allocate memory from memblock. > > > > So, in my view, both flags mean that the memory may be removed and it > > should not be used for certain types of allocations. > > The semantics are different: > > MEMBLOCK_HOTPLUG: memory is indicated as "System RAM" in the > firmware-provided memory map and added to the system early during boot; we > want this memory to be managed by ZONE_MOVABLE with "movable_node" set on > the kernel command line, because only then we want it to be hotpluggable > again. kexec *has to* indicate this memory to the second kernel and can > place kexec-images on this memory. After memory hotunplug, kexec has to be > re-armed. > > MEMBLOCK_DRIVER_MANAGED: memory is not indicated as System RAM" in the > firmware-provided memory map; this memory is always detected and added to > the system by a driver; memory might not actually be physically > hotunpluggable and the ZONE selection does not depend on "movable_core". > kexec *must not* indicate this memory to the second kernel and *must not* > place kexec-images on this memory. Ok, this clarifies. This explanation should be a part of the changelog. The sentences about the zone selection could be probably skipped, because they are less important for this case. E.g something like: MEMBLOCK_HOTPLUG: memory is indicated as "System RAM" in the firmware-provided memory map and added to the system early during boot; kexec *has to* indicate this memory to the second kernel and can place kexec-images on this memory. After memory hotunplug, kexec has to be re-armed. MEMBLOCK_DRIVER_MANAGED: memory is not indicated as "System RAM" in the firmware-provided memory map; this memory is always detected and added to the system by a driver; memory might not actually be physically hotunpluggable. kexec *must not* indicate this memory to the second kernel and *must not* place kexec-images on this memory. -- Sincerely yours, Mike. _______________________________________________ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Date: Fri, 1 Oct 2021 07:03:13 -0700 From: Mike Rapoport Subject: Re: [PATCH v1 3/4] memblock: add MEMBLOCK_DRIVER_MANAGED to mimic IORESOURCE_SYSRAM_DRIVER_MANAGED Message-ID: References: <20210927150518.8607-1-david@redhat.com> <20210927150518.8607-4-david@redhat.com> <830c1670-378b-0fb6-bd5e-208e545fa126@redhat.com> <0d6c86ba-076b-5d4b-33a8-da267f951a85@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0d6c86ba-076b-5d4b-33a8-da267f951a85@redhat.com> 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: David Hildenbrand Cc: linux-kernel@vger.kernel.org, Andrew Morton , Michal Hocko , Oscar Salvador , Jianyong Wu , "Aneesh Kumar K . V" , Vineet Gupta , Geert Uytterhoeven , Huacai Chen , Jiaxun Yang , Thomas Bogendoerfer , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Eric Biederman , Arnd Bergmann , linux-snps-arc@lists.infradead.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-s390@vger.kernel.org, linux-mm@kvack.org, kexec@lists.infradead.org On Fri, Oct 01, 2021 at 10:04:24AM +0200, David Hildenbrand wrote: > On 30.09.21 23:21, Mike Rapoport wrote: > > On Wed, Sep 29, 2021 at 06:54:01PM +0200, David Hildenbrand wrote: > > > On 29.09.21 18:39, Mike Rapoport wrote: > > > > Hi, > > > > > > > > On Mon, Sep 27, 2021 at 05:05:17PM +0200, David Hildenbrand wrote: > > > > > Let's add a flag that corresponds to IORESOURCE_SYSRAM_DRIVER_MANAGED. > > > > > Similar to MEMBLOCK_HOTPLUG, most infrastructure has to treat such memory > > > > > like ordinary MEMBLOCK_NONE memory -- for example, when selecting memory > > > > > regions to add to the vmcore for dumping in the crashkernel via > > > > > for_each_mem_range(). > > > > Can you please elaborate on the difference in semantics of MEMBLOCK_HOTPLUG > > > > and MEMBLOCK_DRIVER_MANAGED? > > > > Unless I'm missing something they both mark memory that can be unplugged > > > > anytime and so it should not be used in certain cases. Why is there a need > > > > for a new flag? > > > > > > In the cover letter I have "Alternative B: Reuse MEMBLOCK_HOTPLUG. > > > MEMBLOCK_HOTPLUG serves a different purpose, though.", but looking into the > > > details it won't work as is. > > > > > > MEMBLOCK_HOTPLUG is used to mark memory early during boot that can later get > > > hotunplugged again and should be placed into ZONE_MOVABLE if the > > > "movable_node" kernel parameter is set. > > > > > > The confusing part is that we talk about "hotpluggable" but really mean > > > "hotunpluggable": the reason is that HW flags DIMM slots that can later be > > > hotplugged as "hotpluggable" even though there is already something > > > hotplugged. > > > > MEMBLOCK_HOTPLUG name is indeed somewhat confusing, but still it's core > > meaning "this memory may be removed" which does not differ from what > > IORESOURCE_SYSRAM_DRIVER_MANAGED means. > > > > MEMBLOCK_HOTPLUG regions are indeed placed into ZONE_MOVABLE, but more > > importantly, they are avoided when we allocate memory from memblock. > > > > So, in my view, both flags mean that the memory may be removed and it > > should not be used for certain types of allocations. > > The semantics are different: > > MEMBLOCK_HOTPLUG: memory is indicated as "System RAM" in the > firmware-provided memory map and added to the system early during boot; we > want this memory to be managed by ZONE_MOVABLE with "movable_node" set on > the kernel command line, because only then we want it to be hotpluggable > again. kexec *has to* indicate this memory to the second kernel and can > place kexec-images on this memory. After memory hotunplug, kexec has to be > re-armed. > > MEMBLOCK_DRIVER_MANAGED: memory is not indicated as System RAM" in the > firmware-provided memory map; this memory is always detected and added to > the system by a driver; memory might not actually be physically > hotunpluggable and the ZONE selection does not depend on "movable_core". > kexec *must not* indicate this memory to the second kernel and *must not* > place kexec-images on this memory. Ok, this clarifies. This explanation should be a part of the changelog. The sentences about the zone selection could be probably skipped, because they are less important for this case. E.g something like: MEMBLOCK_HOTPLUG: memory is indicated as "System RAM" in the firmware-provided memory map and added to the system early during boot; kexec *has to* indicate this memory to the second kernel and can place kexec-images on this memory. After memory hotunplug, kexec has to be re-armed. MEMBLOCK_DRIVER_MANAGED: memory is not indicated as "System RAM" in the firmware-provided memory map; this memory is always detected and added to the system by a driver; memory might not actually be physically hotunpluggable. kexec *must not* indicate this memory to the second kernel and *must not* place kexec-images on this memory. -- Sincerely yours, Mike. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Rapoport Date: Fri, 01 Oct 2021 14:03:13 +0000 Subject: Re: [PATCH v1 3/4] memblock: add MEMBLOCK_DRIVER_MANAGED to mimic IORESOURCE_SYSRAM_DRIVER_MANAGED Message-Id: List-Id: References: <20210927150518.8607-1-david@redhat.com> <20210927150518.8607-4-david@redhat.com> <830c1670-378b-0fb6-bd5e-208e545fa126@redhat.com> <0d6c86ba-076b-5d4b-33a8-da267f951a85@redhat.com> In-Reply-To: <0d6c86ba-076b-5d4b-33a8-da267f951a85@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, Andrew Morton , Michal Hocko , Oscar Salvador , Jianyong Wu , "Aneesh Kumar K . V" , Vineet Gupta , Geert Uytterhoeven , Huacai Chen , Jiaxun Yang , Thomas Bogendoerfer , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Eric Biederman , Arnd Bergmann , linux-snps-arc@lists.infradead.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-s390@vger.kernel.org, linux-mm@kvack.org, kexec@lists.infradead.org On Fri, Oct 01, 2021 at 10:04:24AM +0200, David Hildenbrand wrote: > On 30.09.21 23:21, Mike Rapoport wrote: > > On Wed, Sep 29, 2021 at 06:54:01PM +0200, David Hildenbrand wrote: > > > On 29.09.21 18:39, Mike Rapoport wrote: > > > > Hi, > > > > > > > > On Mon, Sep 27, 2021 at 05:05:17PM +0200, David Hildenbrand wrote: > > > > > Let's add a flag that corresponds to IORESOURCE_SYSRAM_DRIVER_MANAGED. > > > > > Similar to MEMBLOCK_HOTPLUG, most infrastructure has to treat such memory > > > > > like ordinary MEMBLOCK_NONE memory -- for example, when selecting memory > > > > > regions to add to the vmcore for dumping in the crashkernel via > > > > > for_each_mem_range(). > > > > Can you please elaborate on the difference in semantics of MEMBLOCK_HOTPLUG > > > > and MEMBLOCK_DRIVER_MANAGED? > > > > Unless I'm missing something they both mark memory that can be unplugged > > > > anytime and so it should not be used in certain cases. Why is there a need > > > > for a new flag? > > > > > > In the cover letter I have "Alternative B: Reuse MEMBLOCK_HOTPLUG. > > > MEMBLOCK_HOTPLUG serves a different purpose, though.", but looking into the > > > details it won't work as is. > > > > > > MEMBLOCK_HOTPLUG is used to mark memory early during boot that can later get > > > hotunplugged again and should be placed into ZONE_MOVABLE if the > > > "movable_node" kernel parameter is set. > > > > > > The confusing part is that we talk about "hotpluggable" but really mean > > > "hotunpluggable": the reason is that HW flags DIMM slots that can later be > > > hotplugged as "hotpluggable" even though there is already something > > > hotplugged. > > > > MEMBLOCK_HOTPLUG name is indeed somewhat confusing, but still it's core > > meaning "this memory may be removed" which does not differ from what > > IORESOURCE_SYSRAM_DRIVER_MANAGED means. > > > > MEMBLOCK_HOTPLUG regions are indeed placed into ZONE_MOVABLE, but more > > importantly, they are avoided when we allocate memory from memblock. > > > > So, in my view, both flags mean that the memory may be removed and it > > should not be used for certain types of allocations. > > The semantics are different: > > MEMBLOCK_HOTPLUG: memory is indicated as "System RAM" in the > firmware-provided memory map and added to the system early during boot; we > want this memory to be managed by ZONE_MOVABLE with "movable_node" set on > the kernel command line, because only then we want it to be hotpluggable > again. kexec *has to* indicate this memory to the second kernel and can > place kexec-images on this memory. After memory hotunplug, kexec has to be > re-armed. > > MEMBLOCK_DRIVER_MANAGED: memory is not indicated as System RAM" in the > firmware-provided memory map; this memory is always detected and added to > the system by a driver; memory might not actually be physically > hotunpluggable and the ZONE selection does not depend on "movable_core". > kexec *must not* indicate this memory to the second kernel and *must not* > place kexec-images on this memory. Ok, this clarifies. This explanation should be a part of the changelog. The sentences about the zone selection could be probably skipped, because they are less important for this case. E.g something like: MEMBLOCK_HOTPLUG: memory is indicated as "System RAM" in the firmware-provided memory map and added to the system early during boot; kexec *has to* indicate this memory to the second kernel and can place kexec-images on this memory. After memory hotunplug, kexec has to be re-armed. MEMBLOCK_DRIVER_MANAGED: memory is not indicated as "System RAM" in the firmware-provided memory map; this memory is always detected and added to the system by a driver; memory might not actually be physically hotunpluggable. kexec *must not* indicate this memory to the second kernel and *must not* place kexec-images on this memory. -- Sincerely yours, Mike.