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

Ard Biesheuvel ard.biesheuvel at linaro.org
Wed Mar 25 23:22:03 PDT 2015


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



More information about the linux-arm-kernel mailing list