[PATCH 4/4] arm64: align PHYS_OFFSET to block size

[Ard Biesheuvel]

On 26 March 2015 at 07:22, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> On 25 March 2015 at 15:59, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> On Mon, Mar 23, 2015 at 04:36:56PM +0100, Ard Biesheuvel wrote:
>>> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
>>> index 16134608eecf..fd8434753372 100644
>>> --- a/arch/arm64/kernel/head.S
>>> +++ b/arch/arm64/kernel/head.S
>>> @@ -49,13 +49,15 @@
>>>  #ifdef CONFIG_ARM64_64K_PAGES
>>>  #define BLOCK_SHIFT  PAGE_SHIFT
>>>  #define BLOCK_SIZE   PAGE_SIZE
>>> -#define TABLE_SHIFT  PMD_SHIFT
>>>  #else
>>>  #define BLOCK_SHIFT  SECTION_SHIFT
>>>  #define BLOCK_SIZE   SECTION_SIZE
>>> -#define TABLE_SHIFT  PUD_SHIFT
>>>  #endif
>>>
>>> +#define TABLE_SHIFT  (BLOCK_SHIFT + PAGE_SHIFT - 3)
>>> +#define TABLE_SIZE   (1 << TABLE_SHIFT)
>>> +#define TABLE_MASK   (~(TABLE_SIZE - 1))
>>> +
>>>  #define KERNEL_START _text
>>>  #define KERNEL_END   _end
>>>
>>> @@ -237,7 +239,10 @@ ENTRY(stext)
>>>       bl      el2_setup                       // Drop to EL1, w20=cpu_boot_mode
>>>
>>>       adrp    x24, __PHYS_OFFSET
>>> -     mov     x23, #KIMAGE_OFFSET
>>> +     and     x23, x24, #~TABLE_MASK          // image offset
>>> +     and     x24, x24, #TABLE_MASK           // PHYS_OFFSET
>>> +     mov     x0, #KIMAGE_OFFSET
>>> +     add     x23, x23, x0
>>
>> I'm still trying to figure out how this works. Does the code imply that
>> the kernel image can only be loaded within a block size of the
>> PHYS_OFFSET? If that's the case, it's not too flexible.
>>
>
> For now, yes.
>
>> My thoughts were to make PHYS_OFFSET permanently 0 (i.e. get rid of it
>> entirely) or at least compute it at DT parsing time. I'm more inclined
>> for making it 0 assuming that it doesn't break anything else (vmemmap
>> virtual range may get slightly bigger but still not significant,
>> basically max_phys_addr / sizeof(struct page)).
>>
>
> Making it zero would be an improvement, I suppose

Actually, wouldn't that reintroduce a similar VA range problem to the
one I fixed the other day?

On Seattle, with its DRAM at 0x80_0000_0000, you wouldn't have enough
space after PAGE_OFFSET