Re: mm/memblock: export memblock_{start/end}_of_DRAM

Sudarshan Rajagopalan
2020-11-03T13:28:54Z

On 2020-10-30 01:38, Mike Rapoport wrote:
> 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.
>

I don't see how information contained in memblock_{start/end}_of_DRAM()
is considered hidden if the information can be obtained using 'cat
/proc/iomem'. The memory resource manager adds these blocks either in
"System RAM", "reserved", "Kernel data/code" etc. Inspecting this, one
could determine whats the start and end of memblocks.

I agree on the part that its __init annotated and could be removed after
boot. This is something that the driver can be vary of too.

>> 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 meant the physical end address of memblock. The equivalent of
memblock_end_of_DRAM.

>
> I'd suggest you to describe the entire use case in more detail. Having
> the complete picture would help finding a proper solution.

The usecase in general is have a way to add/remove and online/offline
certain memory blocks which are part of boot. We do this by limiting the
memory using "mem=" and latter add the remaining blocks using
add_memory_driver_mamanaged().

>
>> Sudarshan
>>
>
> --
> Sincerely yours,
> Mike.

Sudarshan

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