[PATCH 2/2] arm64: set MAX_MEMBLOCK_ADDR according to linear region size

[Ard Biesheuvel]

On 18 August 2015 at 12:00, Will Deacon <will.deacon at arm.com> wrote:
> On Tue, Aug 18, 2015 at 10:34:42AM +0100, Ard Biesheuvel wrote:
>> The linear region size of a 39-bit VA kernel is only 256 GB, which
>> may be insufficient to cover all of system RAM, even on platforms
>> that have much less than 256 GB of memory but which is laid out
>> very sparsely.
>>
>> So make sure we clip the memory we will not be able to map before
>> installing it into the memblock memory table, by setting
>> MAX_MEMBLOCK_ADDR accordingly.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> ---
>>  arch/arm64/include/asm/memory.h | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> index f800d45ea226..44a59c20e773 100644
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -114,6 +114,14 @@ extern phys_addr_t               memstart_addr;
>>  #define PHYS_OFFSET          ({ memstart_addr; })
>>
>>  /*
>> + * The maximum physical address that the linear direct mapping
>> + * of system RAM can cover. (PAGE_OFFSET can be interpreted as
>> + * a 2's complement signed quantity and negated to derive the
>> + * maximum size of the linear mapping.)
>> + */
>> +#define MAX_MEMBLOCK_ADDR    ({ memstart_addr - PAGE_OFFSET - 1; })
>
> If we initialised memory_limit to this value and changed early_mem to
> use min (i.e. only restrict the limit further), would that avoid the
> need to change the of code? It looks like PPC uses
> memblock_enforce_memory_limit for similar reasons.
>

Yes, that would be yet another way of doing things. But since Catalin
explicitly requested that both checks (i.e., bottom end and top end)
occur in the same place, and indicated his preference not to override
early_init_dt_add_memory_arch() if we can avoid it, the only way is to
hack it in there.

-- 
Ard.