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=-8.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,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 AA800C433E7 for ; Mon, 12 Oct 2020 15:50:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 638772087D for ; Mon, 12 Oct 2020 15:50:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390130AbgJLPuA (ORCPT ); Mon, 12 Oct 2020 11:50:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:51918 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390063AbgJLPuA (ORCPT ); Mon, 12 Oct 2020 11:50:00 -0400 Received: from gaia (unknown [95.149.105.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AB6792076E; Mon, 12 Oct 2020 15:49:57 +0000 (UTC) Date: Mon, 12 Oct 2020 16:49:55 +0100 From: Catalin Marinas To: Ard Biesheuvel Cc: Linux ARM , ACPI Devel Maling List , Will Deacon , Jeremy Linton , Lorenzo Pieralisi , Nicolas Saenz Julienne , Rob Herring , Christoph Hellwig , Robin Murphy , Hanjun Guo , Sudeep Holla , Anshuman Khandual Subject: Re: [PATCH] arm64: mm: set ZONE_DMA size based on early IORT scan Message-ID: <20201012154954.GB6493@gaia> References: <20201010093153.30177-1-ardb@kernel.org> <20201012092821.GB9844@gaia> <20201012112453.GD9844@gaia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Mon, Oct 12, 2020 at 04:19:08PM +0200, Ard Biesheuvel wrote: > On Mon, 12 Oct 2020 at 13:24, Catalin Marinas wrote: > > On Mon, Oct 12, 2020 at 12:43:05PM +0200, Ard Biesheuvel wrote: > > > On Mon, 12 Oct 2020 at 11:30, Ard Biesheuvel wrote: > > > > On Mon, 12 Oct 2020 at 11:28, Catalin Marinas wrote: > > > > > On Sat, Oct 10, 2020 at 11:31:53AM +0200, Ard Biesheuvel wrote: > > > > > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > > > > > > index f0599ae73b8d..829fa63c3d72 100644 > > > > > > --- a/arch/arm64/mm/init.c > > > > > > +++ b/arch/arm64/mm/init.c > > > > > > @@ -191,6 +191,14 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max) > > > > > > unsigned long max_zone_pfns[MAX_NR_ZONES] = {0}; > > > > > > > > > > > > #ifdef CONFIG_ZONE_DMA > > > > > > + if (IS_ENABLED(CONFIG_ACPI)) { > > > > > > + extern unsigned int acpi_iort_get_zone_dma_size(void); > > > > > > > > > > Nitpick: can we add this prototype to include/linux/acpi_iort.h? > > > > > > > > > > > + > > > > > > + zone_dma_bits = min(zone_dma_bits, > > > > > > + acpi_iort_get_zone_dma_size()); > > > > > > + arm64_dma_phys_limit = max_zone_phys(zone_dma_bits); > > > > > > + } > > > > > > + > > > > > > max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit); > > > > > > > > > > I think we should initialise zone_dma_bits slightly earlier via > > > > > arm64_memblock_init(). We'll eventually have reserve_crashkernel() > > > > > called before this and it will make use of arm64_dma_phys_limit for > > > > > "low" reservations: > > > > > > > > > > https://lore.kernel.org/linux-arm-kernel/20200907134745.25732-7-chenzhou10@huawei.com/ > > > > > > > > > > > > > We don't have access to the ACPI tables yet at that point. > > > > > > Also, could someone give an executive summary of why it matters where > > > the crashkernel is loaded? As far as I can tell, reserve_crashkernel() > > > only allocates memory for the kernel's executable image itself, which > > > can usually be loaded anywhere in memory. I could see how a > > > crashkernel might need some DMA'able memory if it needs to use the > > > hardware, but I don't think that is what is going on here. > > > > I thought the crashkernel needs some additional reserved RAM as well to > > be able to run. It should not touch the original kernel's memory as it > > usually needs to dump it. > > Looking at the code, it is definitely allocating memory for the kernel > itself (as it refers to the 2 MB alignment requirement), and given > that we used to require the kernel to be at the base of the linear > region to even be able to access all of memory, I suspect that we > might be able to relax this requirement. Not sure what that means for > the userland tools, though. The 2MB is an interpretation of booting.txt that the DRAM must start at this alignment (not sure what we do these days, in lots of configurations we just use 4K pages for the linear map). However, the crashkernel=... range is meant for sufficiently large reservation to be able to run the kdump kernel, not just load the image. -- Catalin