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 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,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 2A8DFC43457 for ; Mon, 12 Oct 2020 15:51:19 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 B76382076E for ; Mon, 12 Oct 2020 15:51:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="jnNTWgG+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B76382076E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.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:References:Message-ID: Subject: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=Jkl65AMJtpE+bxclyLMKo9xWRgUnSPNdZ0Isg3vaCYo=; b=jnNTWgG+S5gClXztMpZosTBt7 njGdF4PsmDHl2N+YXpw9tlTYKgcBnwniCeoby68xlvWyDlH3cRIxLN2mhW93FYuOtssCqQAbFRXBW nhI9NLBS3A5ewm74hEaVKN9I0Lckanl8VC7ZvTl2xYz9A3qWvCSZqBBfzkM0RGS+IsI//DHu448Jd ttkVI5I2dkqrfJKdePZE43SJFUeeeDbFjFkhQiltiPBM6HZ0Kq6n4fDzz+5EsnGmwqa7pqOWhJKMe FG/MECCz9fO70PlRtCpvPPFdR3d81KC7+0dSPmZjTD4PY6lMTs3NKHUmWXcD45K6eC31+5bJOUy7D kXcaJGQtg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kS05M-0004di-4J; Mon, 12 Oct 2020 15:50:04 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kS05J-0004cM-66 for linux-arm-kernel@lists.infradead.org; Mon, 12 Oct 2020 15:50:02 +0000 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 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-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-20201012_115001_391431_055EC769 X-CRM114-Status: GOOD ( 34.38 ) 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: Lorenzo Pieralisi , Anshuman Khandual , Robin Murphy , Sudeep Holla , Jeremy Linton , ACPI Devel Maling List , Rob Herring , Linux ARM , Hanjun Guo , Will Deacon , Christoph Hellwig , Nicolas Saenz Julienne 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, 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel