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

[Sudarshan Rajagopalan]

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