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 6381FC433EF for ; Mon, 13 Dec 2021 19:09:00 +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=x0n5xLDXeui5OsAs3YeuaFS4J3SoYlw9WZtJs88ZjLE=; b=nFjMfgXuDRWGWp VxoC8w5FDOSTa5qg9ZTMGHq2cnWb0TApkbwYmJqJuc8QGrLINB21PRoBNpHHgOKfX1uSoeyUZdMR5 u1cV9mU4O8ZPmpNxsEmd/3dAgy43V4gNlQc1+DPzTNhvcoSZ80pd0c1AfpzBeODepHvzY9i4Z0ekC xXmJ9cvZcA0RWkydXPPAzpEGi7iNlqh2l3Fj6LVlYw1VaUJj+Nxf8Igfg0SIMwIPkPG6Va1/jH4jr Ynaw/D+qRoPVWXNZ7N42deb/Jmr/uTgXVAbA3fxMSZOJMEtZjIwL/xgEGIWvNQja2p95DQvpmghe6 C3hDRMIEtfV/nrevZUwA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mwqfk-00B544-0p; Mon, 13 Dec 2021 19:07:40 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mwqfg-00B52L-Db for linux-arm-kernel@lists.infradead.org; Mon, 13 Dec 2021 19:07:37 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 272F2611CB; Mon, 13 Dec 2021 19:07:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 09A5DC34602; Mon, 13 Dec 2021 19:07:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1639422454; bh=3AY7rttIyiTIK3sDPCcxzSfht2B/FJyUaqknEEyyUa0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=p4MCi32NTnabbFCT63oPHhRCpVsGal/CQnAO9iUg/nO/cLPSCYTFSfXa0wF/1fgJk tqxcxbqffsMuTQZ94Dr1+k72hqVYt7Q9R45dil+8bRwFJasEHbeqpFUMNSpTyab649 Dd69ZYSI1HwWEoRngsxzeIelhfHL8bhH84IORzX1r/KeZB6HMDjK0XxvCTtUX7e8sK iHfLcDyX/GNFHIFOKOeLGMT0A3p8NJNUWjv2poRYf+ky8MnxSKgKIMNOWLYoZX1vDc l1/N/Awu1NKS9sE2ftIEhmA6ZuFIL++1fYprbuMzaAOjwQxTd+RRAt5Y5/HGTyanov Lb3sQ2+eMpf5Q== Date: Mon, 13 Dec 2021 19:07:29 +0000 From: Will Deacon To: Huacai Chen Cc: Huacai Chen , Catalin Marinas , Arnd Bergmann , linux-arm-kernel , Jiaxun Yang , Ard Biesheuvel , mark.rutland@arm.com Subject: Re: [PATCH] arm64: Use correct method to calculate nomap region boundaries Message-ID: <20211213190729.GA12778@willie-the-truck> References: <20211022070646.41923-1-chenhuacai@loongson.cn> <20211202100813.GA26450@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211213_110736_562904_200BE254 X-CRM114-Status: GOOD ( 25.88 ) 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 Mon, Dec 06, 2021 at 12:46:27PM +0800, Huacai Chen wrote: > On Thu, Dec 2, 2021 at 6:08 PM Will Deacon wrote: > > On Fri, Oct 22, 2021 at 03:06:46PM +0800, Huacai Chen wrote: > > > Nomap regions are treated as "reserved". When region boundaries are not > > > page aligned, we usually increase the "reserved" regions rather than > > > decrease them. So, we should use memblock_region_reserved_base_pfn()/ > > > memblock_region_reserved_end_pfn() instead of memblock_region_memory_ > > > base_pfn()/memblock_region_memory_base_pfn() to calculate boundaries. > > > > > > Signed-off-by: Huacai Chen > > > --- > > > arch/arm64/kernel/setup.c | 6 ++++-- > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c > > > index be5f85b0a24d..1e86d4c5ef8c 100644 > > > --- a/arch/arm64/kernel/setup.c > > > +++ b/arch/arm64/kernel/setup.c > > > @@ -232,12 +232,14 @@ static void __init request_standard_resources(void) > > > if (memblock_is_nomap(region)) { > > > res->name = "reserved"; > > > res->flags = IORESOURCE_MEM; > > > + res->start = __pfn_to_phys(memblock_region_reserved_base_pfn(region)); > > > + res->end = __pfn_to_phys(memblock_region_reserved_end_pfn(region)) - 1; > > > } else { > > > res->name = "System RAM"; > > > res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; > > > + res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region)); > > > + res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1; > > > } > > > - res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region)); > > > - res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1; > > > > Under which circumstances would the nomap regions not be page-aligned? That > > sounds like something we should prevent, rather than work around here. > > In this call path: > acpi_table_upgrade --> arch_reserve_mem_area --> memblock_mark_nomap > The nomap region is not page-aligned. Fair enough, then I think this patch is probably doing the right thing. However, Ard and Mark had some concerns about the new behaviour wrt adjacent nomap regions where the page containing the overlap would be reported twice. Is this a problem? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel