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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 D2DEBC00A89 for ; Fri, 30 Oct 2020 08:38:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 693162083B for ; Fri, 30 Oct 2020 08:38:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604047132; bh=5pnaYeg0slp/C6LJW0tZt7NwF2KtZxhAKuysRfnP6vg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=V7fnpIj3g/WgFhSENygaBrb25cj5P2vJT1rNUNOswz3zR9ZzTcKgjn4JEIvEq7ykG DLRcpeIWu02v4eBNZOeNMCXBQpGz6DkARcdsiTwG3gikH9cSX0I16i3g2ke992+SaP moQ/Je+vc1VytGdQNgpdMZdKPGqtpMPk6o+h68M4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726019AbgJ3Iiv (ORCPT ); Fri, 30 Oct 2020 04:38:51 -0400 Received: from mail.kernel.org ([198.145.29.99]:50062 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725355AbgJ3Iiv (ORCPT ); Fri, 30 Oct 2020 04:38:51 -0400 Received: from kernel.org (unknown [87.71.17.26]) (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 B2FB62075E; Fri, 30 Oct 2020 08:38:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604047130; bh=5pnaYeg0slp/C6LJW0tZt7NwF2KtZxhAKuysRfnP6vg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Gub5VpJy/YKwwNSXMPAehOYKrC3ZbBRzR+owx6+zxhiDElhexw2Rjmwo8LSt+G9qO DphIEXohytWWawhFH2y7mnynjSHE/ZNRtpKmHZYAKratdTBUOeJ5Hpd2U+St3EbTf2 fhtkkWeIaBP95rcXFwQ1RMEiJd1jZPaJUolALiSE= Date: Fri, 30 Oct 2020 10:38:42 +0200 From: Mike Rapoport To: Sudarshan Rajagopalan Cc: Anshuman Khandual , Mark Rutland , David Hildenbrand , Steven Price , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Catalin Marinas , Will Deacon , Suren Baghdasaryan , Greg Kroah-Hartman , Pratik Patel Subject: Re: mm/memblock: export memblock_{start/end}_of_DRAM Message-ID: <20201030083842.GA4319@kernel.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 29, 2020 at 02:29:27PM -0700, Sudarshan Rajagopalan wrote: > Hello all, > > We have a usecase where a module driver adds certain memory blocks using > add_memory_driver_managed(), so that it can perform memory hotplug > operations on these blocks. In general, these memory blocks aren’t something > that gets physically added later, but is part of actual RAM that system > booted up with. Meaning – we set the ‘mem=’ cmdline parameter to limit the > memory and later add the remaining ones using add_memory*() variants. > > The basic idea is to have driver have ownership and manage certain memory > blocks for hotplug operations. > > For the driver be able to know how much memory was limited and how much > actually present, we take the delta of ‘bootmem physical end address’ and > ‘memblock_end_of_DRAM’. The 'bootmem physical end address' is obtained by > scanning the reg values in ‘memory’ DT node and determining the max > {addr,size}. Since our driver is getting modularized, we won’t have access > to memblock_end_of_DRAM (i.e. end address of all memory blocks after ‘mem=’ > is applied). > > So checking if memblock_{start/end}_of_DRAM() symbols can be exported? Also, > this information can be obtained by userspace by doing ‘cat /proc/iomem’ and > greping for ‘System RAM’. So wondering if userspace can have access to such > info, can we allow kernel module drivers have access by exporting > memblock_{start/end}_of_DRAM(). These functions cannot be exported not because we want to hide this information from the modules but because it is unsafe to use them. On most architecturs these functions are __init so they are discarded after boot anyway. Beisdes, the memory configuration known to memblock might be not accurate in many cases as David explained in his reply. > Or are there any other ways where a module driver can get the end address of > system memory block? What do you mean by "system memory block"? There could be a lot of interpretations if you take into account memory hotplug, "mem=" option, reserved and firmware memory. I'd suggest you to describe the entire use case in more detail. Having the complete picture would help finding a proper solution. > Sudarshan > -- Sincerely yours, Mike.