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

On 26 March 2015 at 07:22, Ard Biesheuvel [off-list ref] wrote:

On 25 March 2015 at 15:59, Catalin Marinas [off-list ref] wrote:

quoted

On Mon, Mar 23, 2015 at 04:36:56PM +0100, Ard Biesheuvel wrote:

quoted

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.

quoted

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