linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sudarshan Rajagopalan <sudaraja@codeaurora.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	David Hildenbrand <david@redhat.com>,
	Steven Price <steven.price@arm.com>,
	Mike Rapoport <rppt@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Greg Kroah-Hartman <gregkh@google.com>,
	Pratik Patel <pratikp@codeaurora.org>
Subject: mm/memblock: export memblock_{start/end}_of_DRAM
Date: Thu, 29 Oct 2020 14:29:27 -0700	[thread overview]
Message-ID: <d0580051d03df3f3e9f333f6bfe968cf@codeaurora.org> (raw)

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().

Or are there any other ways where a module driver can get the end 
address of system memory block?


Sudarshan

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

             reply	other threads:[~2020-10-29 21:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-29 21:29 Sudarshan Rajagopalan [this message]
2020-10-30  6:41 ` mm/memblock: export memblock_{start/end}_of_DRAM David Hildenbrand
2020-11-03  2:15   ` Sudarshan Rajagopalan
2020-10-30  8:38 ` Mike Rapoport
2020-10-31  9:18   ` Christoph Hellwig
2020-10-31 10:05     ` David Hildenbrand
2020-11-03  8:38       ` Christoph Hellwig
2020-11-03  2:51   ` Sudarshan Rajagopalan
2020-11-03 16:51     ` Mike Rapoport

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d0580051d03df3f3e9f333f6bfe968cf@codeaurora.org \
    --to=sudaraja@codeaurora.org \
    --cc=anshuman.khandual@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=david@redhat.com \
    --cc=gregkh@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pratikp@codeaurora.org \
    --cc=rppt@kernel.org \
    --cc=steven.price@arm.com \
    --cc=surenb@google.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).