Date:   Mon, 02 Nov 2020 18:51:25 -0800
From:   Sudarshan Rajagopalan <sudaraja@...eaurora.org>
To:     Mike Rapoport <rppt@...nel.org>
Cc:     Anshuman Khandual <anshuman.khandual@....com>,
        Mark Rutland <mark.rutland@....com>,
        David Hildenbrand <david@...hat.com>,
        Steven Price <steven.price@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Suren Baghdasaryan <surenb@...gle.com>,
        Greg Kroah-Hartman <gregkh@...gle.com>,
        Pratik Patel <pratikp@...eaurora.org>
Subject: Re: mm/memblock: export memblock_{start/end}_of_DRAM

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

Powered by blists - more mailing lists