[1/3] powerpc/book3s64/hash/4k: 4k supports only 16TB linear mapping

With commit: 0034d395f89d ("powerpc/mm/hash64: Map all the kernel regions in the
same 0xc range"), we now split the 64TB address range into 4 contexts each of
16TB. That implies we can do only 16TB linear mapping. Make sure we don't
add physical memory above 16TB if that is present in the system.

Fixes: 0034d395f89d ("powerpc/mm/hash64: Map all the kernel regions in thesame 0xc range")
Reported-by: Cameron Berkenpas <cam@neo-zeon.de>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
 arch/powerpc/include/asm/book3s/64/mmu.h | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

On Tue, 2019-09-17 at 14:57:00 UTC, "Aneesh Kumar K.V" wrote:
> With commit: 0034d395f89d ("powerpc/mm/hash64: Map all the kernel regions in the
> same 0xc range"), we now split the 64TB address range into 4 contexts each of
> 16TB. That implies we can do only 16TB linear mapping. Make sure we don't
> add physical memory above 16TB if that is present in the system.
> 
> Fixes: 0034d395f89d ("powerpc/mm/hash64: Map all the kernel regions in thesame 0xc range")
> Reported-by: Cameron Berkenpas <cam@neo-zeon.de>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/e422bd3330e5bc5cd76b063d9fc3a21cd06d9957

cheers

Hello,

On 9/17/19 9:57 AM, Aneesh Kumar K.V wrote:
> With commit: 0034d395f89d ("powerpc/mm/hash64: Map all the kernel regions in the
> same 0xc range"), we now split the 64TB address range into 4 contexts each of
> 16TB. That implies we can do only 16TB linear mapping. Make sure we don't
> add physical memory above 16TB if that is present in the system.
> 
> Fixes: 0034d395f89d ("powerpc/mm/hash64: Map all the kernel regions in thesame 0xc range")
> Reported-by: Cameron Berkenpas <cam@neo-zeon.de>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
>  arch/powerpc/include/asm/book3s/64/mmu.h | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h b/arch/powerpc/include/asm/book3s/64/mmu.h
> index bb3deb76c951..86cce8189240 100644
> --- a/arch/powerpc/include/asm/book3s/64/mmu.h
> +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
> @@ -35,12 +35,16 @@ extern struct mmu_psize_def mmu_psize_defs[MMU_PAGE_COUNT];
>   * memory requirements with large number of sections.
>   * 51 bits is the max physical real address on POWER9
>   */
> -#if defined(CONFIG_SPARSEMEM_VMEMMAP) && defined(CONFIG_SPARSEMEM_EXTREME) &&  \
> -	defined(CONFIG_PPC_64K_PAGES)
> +
> +#if defined(CONFIG_PPC_64K_PAGES)
> +#if defined(CONFIG_SPARSEMEM_VMEMMAP) && defined(CONFIG_SPARSEMEM_EXTREME)

This prevents accessing physical memory over 16TB with 4k pages and radix MMU as
well. Was this intentional?

>  #define MAX_PHYSMEM_BITS 51
>  #else
>  #define MAX_PHYSMEM_BITS 46
>  #endif
> +#else /* CONFIG_PPC_64K_PAGES */
> +#define MAX_PHYSMEM_BITS 44
> +#endif
>  
>  /* 64-bit classic hash table MMU */
>  #include <asm/book3s/64/mmu-hash.h>
> 
Cheers,
Samuel

Samuel Holland <samuel@sholland.org> writes:
> Hello,
>
> On 9/17/19 9:57 AM, Aneesh Kumar K.V wrote:
>> With commit: 0034d395f89d ("powerpc/mm/hash64: Map all the kernel regions in the
>> same 0xc range"), we now split the 64TB address range into 4 contexts each of
>> 16TB. That implies we can do only 16TB linear mapping. Make sure we don't
>> add physical memory above 16TB if that is present in the system.
>> 
>> Fixes: 0034d395f89d ("powerpc/mm/hash64: Map all the kernel regions in thesame 0xc range")
>> Reported-by: Cameron Berkenpas <cam@neo-zeon.de>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>> ---
>>  arch/powerpc/include/asm/book3s/64/mmu.h | 8 ++++++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>> 
>> diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h b/arch/powerpc/include/asm/book3s/64/mmu.h
>> index bb3deb76c951..86cce8189240 100644
>> --- a/arch/powerpc/include/asm/book3s/64/mmu.h
>> +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
>> @@ -35,12 +35,16 @@ extern struct mmu_psize_def mmu_psize_defs[MMU_PAGE_COUNT];
>>   * memory requirements with large number of sections.
>>   * 51 bits is the max physical real address on POWER9
>>   */
>> -#if defined(CONFIG_SPARSEMEM_VMEMMAP) && defined(CONFIG_SPARSEMEM_EXTREME) &&  \
>> -	defined(CONFIG_PPC_64K_PAGES)
>> +
>> +#if defined(CONFIG_PPC_64K_PAGES)
>> +#if defined(CONFIG_SPARSEMEM_VMEMMAP) && defined(CONFIG_SPARSEMEM_EXTREME)
>
> This prevents accessing physical memory over 16TB with 4k pages and radix MMU as
> well. Was this intentional?

No, it was meant to be a temporary fix until the rest of Aneesh's series
fixed things up properly, but then there were problems with those
patches so he asked me to just pick up this one.

At the moment 4K hash won't boot at all if you have too much RAM on P9,
so this was meant to at least avoid that.

But breaking 4K radix is arguably worse, so I'll drop this for now.

cheers