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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 10EAFC433EF for ; Thu, 13 Jan 2022 17:33:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234448AbiAMRdX (ORCPT ); Thu, 13 Jan 2022 12:33:23 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:58284 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229675AbiAMRdV (ORCPT ); Thu, 13 Jan 2022 12:33:21 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 75CFF61CF4; Thu, 13 Jan 2022 17:33:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C804C36AE9; Thu, 13 Jan 2022 17:33:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1642095200; bh=kTQ0RXYCVzEJELAfnWtXQDxddDbKHo6D1Ei14G+EQHE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NxBJeuvDtGQbr0LbThSZ2HVyPJ5cxzw8itQLvCWUTjMiU/YvloyTJCRTYf8zwSu61 8ItjDqmR4xOhz3Yf5QAqI6f6hhT7wZxL/l/SXa+KYfDd5I+bgtbqpro+1z2bt6wldo KSa1OsX/m+Z3Shyc6S56BcwTUBy+WYuTeA9VPVrQrRqDuLDZHan5NMjJZVd32/7SFB eVA/4xbS86b/bkZKikDOW5tr3760HDpjHbDeVAd7BVLG5S6dAN4Lh1eXCychO76I/R IyrlyFsLKjpJJe1ZbbNG4BwGyghMBuxhkE70dn3rhvyOLqRjKGhF1VhC8Ero14Iouc AZRxv0/JHYnYQ== Date: Thu, 13 Jan 2022 19:33:11 +0200 From: Mike Rapoport To: Frank van der Linden Cc: linux-arm-kernel@lists.infradead.org, robh+dt@kernel.org, frowand.list@gmail.com, ardb@kernel.org, linux-mm@kvack.org, devicetree@vger.kernel.org, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, catalin.marinas@arm.com, will@kernel.org, geert+renesas@glider.be Subject: Re: [PATCH 1/3] memblock: define functions to set the usable memory range Message-ID: References: <20220110210809.3528-1-fllinden@amazon.com> <20220110210809.3528-2-fllinden@amazon.com> <20220111204441.GA36458@dev-dsk-fllinden-2c-d7720709.us-west-2.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220111204441.GA36458@dev-dsk-fllinden-2c-d7720709.us-west-2.amazon.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 11, 2022 at 08:44:41PM +0000, Frank van der Linden wrote: > On Tue, Jan 11, 2022 at 12:31:58PM +0200, Mike Rapoport wrote: > > > --- a/include/linux/memblock.h > > > +++ b/include/linux/memblock.h > > > @@ -481,6 +481,8 @@ phys_addr_t memblock_reserved_size(void); > > > phys_addr_t memblock_start_of_DRAM(void); > > > phys_addr_t memblock_end_of_DRAM(void); > > > void memblock_enforce_memory_limit(phys_addr_t memory_limit); > > > +void memblock_set_usable_range(phys_addr_t base, phys_addr_t size); > > > +void memblock_enforce_usable_range(void); > > > void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size); > > > void memblock_mem_limit_remove_map(phys_addr_t limit); > > > > We already have 3 very similar interfaces that deal with memory capping. > > Now you suggest to add fourth that will "generically" solve a single use > > case of DT, EFI and kdump interaction on arm64. > > > > Looks like a workaround for a fundamental issue of incompatibility between > > DT and EFI wrt memory registration. > > Yep, I figured this would be the main argument against this - arm64 > already added several other more-or-less special cased interfaces over > time. > > I'm more than happy to solve this in a different way. > > What would you suggest: > > 1) Try to merge the similar interfaces in to one. > 2) Just deal with it at a lower (arm64) level? > 3) Some other way? We've discussed this with Ard on IRC, and our conclusion was that on arm64 kdump kernel should have memblock.memory exactly the same as the normal kernel. Then, the memory outside usable-memory-range should be reserved so that kdump kernel won't step over it. With that, simple (untested) patch below could be what we need: diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c index bdca35284ceb..371418dffaf1 100644 --- a/drivers/of/fdt.c +++ b/drivers/of/fdt.c @@ -1275,7 +1275,8 @@ void __init early_init_dt_scan_nodes(void) of_scan_flat_dt(early_init_dt_scan_memory, NULL); /* Handle linux,usable-memory-range property */ - memblock_cap_memory_range(cap_mem_addr, cap_mem_size); + memblock_reserve(0, cap_mem_addr); + memblock_reserve(cap_mem_addr + cap_mem_size, PHYS_ADDR_MAX); } bool __init early_init_dt_scan(void *params) > Thanks, > > - Frank > -- 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id A63A4C433EF for ; Thu, 13 Jan 2022 17:34:41 +0000 (UTC) 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=blyaRS3pJ80QYDmQXO40W3+VUfsaWJgqTh0K9xJDhbI=; b=pY8lXozskw7wFw 0QQ0WtDxtGpmzsYMETuEoL0ziXt5OCAn7E/2wTw/MttQVNocb72cpUFPaAXXnFchcOsYpnNaKO6Wt 5orMgJ886nrKkUHaRKfCeMgvZQGy9Q5me6Cq2NN9GiMxnDu3a5CWkMylv77zQilPrC8oxgo2z3yU3 qefBCcIgK3r+1UW7UqKPsab3NZy7M9lZkdfs2vjDB2CIMdV8ykinQUjpiTgzv1/dRT8t1fApfzZZl Xn8Y8r6cvPnQgZQcXp/a1oOx0M793HcvSaYQk+hz8+OXL1D6DnmX6bu5qSaGVVv0Volq97dpv6PAC zxBayPTuF/1naoK23TUQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n83yb-006lLQ-Bt; Thu, 13 Jan 2022 17:33:29 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n83yW-006lK2-0G; Thu, 13 Jan 2022 17:33:25 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 2ACB6B8230E; Thu, 13 Jan 2022 17:33:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C804C36AE9; Thu, 13 Jan 2022 17:33:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1642095200; bh=kTQ0RXYCVzEJELAfnWtXQDxddDbKHo6D1Ei14G+EQHE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NxBJeuvDtGQbr0LbThSZ2HVyPJ5cxzw8itQLvCWUTjMiU/YvloyTJCRTYf8zwSu61 8ItjDqmR4xOhz3Yf5QAqI6f6hhT7wZxL/l/SXa+KYfDd5I+bgtbqpro+1z2bt6wldo KSa1OsX/m+Z3Shyc6S56BcwTUBy+WYuTeA9VPVrQrRqDuLDZHan5NMjJZVd32/7SFB eVA/4xbS86b/bkZKikDOW5tr3760HDpjHbDeVAd7BVLG5S6dAN4Lh1eXCychO76I/R IyrlyFsLKjpJJe1ZbbNG4BwGyghMBuxhkE70dn3rhvyOLqRjKGhF1VhC8Ero14Iouc AZRxv0/JHYnYQ== Date: Thu, 13 Jan 2022 19:33:11 +0200 From: Mike Rapoport To: Frank van der Linden Cc: linux-arm-kernel@lists.infradead.org, robh+dt@kernel.org, frowand.list@gmail.com, ardb@kernel.org, linux-mm@kvack.org, devicetree@vger.kernel.org, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, catalin.marinas@arm.com, will@kernel.org, geert+renesas@glider.be Subject: Re: [PATCH 1/3] memblock: define functions to set the usable memory range Message-ID: References: <20220110210809.3528-1-fllinden@amazon.com> <20220110210809.3528-2-fllinden@amazon.com> <20220111204441.GA36458@dev-dsk-fllinden-2c-d7720709.us-west-2.amazon.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220111204441.GA36458@dev-dsk-fllinden-2c-d7720709.us-west-2.amazon.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220113_093324_350219_903E4B10 X-CRM114-Status: GOOD ( 21.95 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jan 11, 2022 at 08:44:41PM +0000, Frank van der Linden wrote: > On Tue, Jan 11, 2022 at 12:31:58PM +0200, Mike Rapoport wrote: > > > --- a/include/linux/memblock.h > > > +++ b/include/linux/memblock.h > > > @@ -481,6 +481,8 @@ phys_addr_t memblock_reserved_size(void); > > > phys_addr_t memblock_start_of_DRAM(void); > > > phys_addr_t memblock_end_of_DRAM(void); > > > void memblock_enforce_memory_limit(phys_addr_t memory_limit); > > > +void memblock_set_usable_range(phys_addr_t base, phys_addr_t size); > > > +void memblock_enforce_usable_range(void); > > > void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size); > > > void memblock_mem_limit_remove_map(phys_addr_t limit); > > > > We already have 3 very similar interfaces that deal with memory capping. > > Now you suggest to add fourth that will "generically" solve a single use > > case of DT, EFI and kdump interaction on arm64. > > > > Looks like a workaround for a fundamental issue of incompatibility between > > DT and EFI wrt memory registration. > > Yep, I figured this would be the main argument against this - arm64 > already added several other more-or-less special cased interfaces over > time. > > I'm more than happy to solve this in a different way. > > What would you suggest: > > 1) Try to merge the similar interfaces in to one. > 2) Just deal with it at a lower (arm64) level? > 3) Some other way? We've discussed this with Ard on IRC, and our conclusion was that on arm64 kdump kernel should have memblock.memory exactly the same as the normal kernel. Then, the memory outside usable-memory-range should be reserved so that kdump kernel won't step over it. With that, simple (untested) patch below could be what we need: diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c index bdca35284ceb..371418dffaf1 100644 --- a/drivers/of/fdt.c +++ b/drivers/of/fdt.c @@ -1275,7 +1275,8 @@ void __init early_init_dt_scan_nodes(void) of_scan_flat_dt(early_init_dt_scan_memory, NULL); /* Handle linux,usable-memory-range property */ - memblock_cap_memory_range(cap_mem_addr, cap_mem_size); + memblock_reserve(0, cap_mem_addr); + memblock_reserve(cap_mem_addr + cap_mem_size, PHYS_ADDR_MAX); } bool __init early_init_dt_scan(void *params) > Thanks, > > - Frank > -- Sincerely yours, Mike. _______________________________________________ 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 From: Mike Rapoport Date: Thu, 13 Jan 2022 19:33:11 +0200 Subject: [PATCH 1/3] memblock: define functions to set the usable memory range In-Reply-To: <20220111204441.GA36458@dev-dsk-fllinden-2c-d7720709.us-west-2.amazon.com> References: <20220110210809.3528-1-fllinden@amazon.com> <20220110210809.3528-2-fllinden@amazon.com> <20220111204441.GA36458@dev-dsk-fllinden-2c-d7720709.us-west-2.amazon.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kexec@lists.infradead.org On Tue, Jan 11, 2022 at 08:44:41PM +0000, Frank van der Linden wrote: > On Tue, Jan 11, 2022 at 12:31:58PM +0200, Mike Rapoport wrote: > > > --- a/include/linux/memblock.h > > > +++ b/include/linux/memblock.h > > > @@ -481,6 +481,8 @@ phys_addr_t memblock_reserved_size(void); > > > phys_addr_t memblock_start_of_DRAM(void); > > > phys_addr_t memblock_end_of_DRAM(void); > > > void memblock_enforce_memory_limit(phys_addr_t memory_limit); > > > +void memblock_set_usable_range(phys_addr_t base, phys_addr_t size); > > > +void memblock_enforce_usable_range(void); > > > void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size); > > > void memblock_mem_limit_remove_map(phys_addr_t limit); > > > > We already have 3 very similar interfaces that deal with memory capping. > > Now you suggest to add fourth that will "generically" solve a single use > > case of DT, EFI and kdump interaction on arm64. > > > > Looks like a workaround for a fundamental issue of incompatibility between > > DT and EFI wrt memory registration. > > Yep, I figured this would be the main argument against this - arm64 > already added several other more-or-less special cased interfaces over > time. > > I'm more than happy to solve this in a different way. > > What would you suggest: > > 1) Try to merge the similar interfaces in to one. > 2) Just deal with it at a lower (arm64) level? > 3) Some other way? We've discussed this with Ard on IRC, and our conclusion was that on arm64 kdump kernel should have memblock.memory exactly the same as the normal kernel. Then, the memory outside usable-memory-range should be reserved so that kdump kernel won't step over it. With that, simple (untested) patch below could be what we need: diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c index bdca35284ceb..371418dffaf1 100644 --- a/drivers/of/fdt.c +++ b/drivers/of/fdt.c @@ -1275,7 +1275,8 @@ void __init early_init_dt_scan_nodes(void) of_scan_flat_dt(early_init_dt_scan_memory, NULL); /* Handle linux,usable-memory-range property */ - memblock_cap_memory_range(cap_mem_addr, cap_mem_size); + memblock_reserve(0, cap_mem_addr); + memblock_reserve(cap_mem_addr + cap_mem_size, PHYS_ADDR_MAX); } bool __init early_init_dt_scan(void *params) > Thanks, > > - Frank > -- Sincerely yours, Mike.