arm64: relax Image placement rules

By default, early_init_dt_add_memory_arch() ignores memory below the base of the kernel image since it won't be addressable via the linear mapping. However, this is not appropriate anymore once we decouple the kernel text mapping from the linear mapping, so archs may want to drop the low limit entirely. So allow the minimum to be overridden by setting MIN_MEMBLOCK_ADDR.

Signed-off-by Ard Biesheuvel <[email protected]>

---
 drivers/of/fdt.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/of/fdt.c +4 -1

index 6e82bc42373b..5e7ef800a816 100644
@@ -967,13 +967,16 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
 }
 
 #ifdef CONFIG_HAVE_MEMBLOCK
+#ifndef MIN_MEMBLOCK_ADDR
+#define MIN_MEMBLOCK_ADDR	__pa(PAGE_OFFSET)
+#endif
 #ifndef MAX_MEMBLOCK_ADDR
 #define MAX_MEMBLOCK_ADDR	((phys_addr_t)~0)
 #endif
 
 void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
 {
-	const u64 phys_offset = __pa(PAGE_OFFSET);
+	const u64 phys_offset = MIN_MEMBLOCK_ADDR;
 
 	if (!PAGE_ALIGNED(base)) {
 		if (size < PAGE_SIZE - (base & ~PAGE_MASK)) {

Signature · 1 line

1.9.1

By default, early_init_dt_add_memory_arch() ignores memory below the base of the kernel image since it won't be addressable via the linear mapping. However, this is not appropriate anymore once we decouple the kernel text mapping from the linear mapping, so archs may want to drop the low limit entirely. So allow the minimum to be overridden by setting MIN_MEMBLOCK_ADDR.

Signed-off-by Ard Biesheuvel <[email protected]>

---
 drivers/of/fdt.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/of/fdt.c +4 -2

index 6e82bc42373b..5e7ef800a816 100644
@@ -967,13 +967,16 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
 }
 
 #ifdef CONFIG_HAVE_MEMBLOCK
+#ifndef MIN_MEMBLOCK_ADDR
+#define MIN_MEMBLOCK_ADDR      __pa(PAGE_OFFSET)
+#endif
 #ifndef MAX_MEMBLOCK_ADDR
 #define MAX_MEMBLOCK_ADDR      ((phys_addr_t)~0)
 #endif
 
 void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
 {
-       const u64 phys_offset = __pa(PAGE_OFFSET);
+       const u64 phys_offset = MIN_MEMBLOCK_ADDR;
 
        if (!PAGE_ALIGNED(base)) {
                if (size < PAGE_SIZE - (base & ~PAGE_MASK)) {
--

1.9.1

This relaxes the kernel Image placement requirements, so that it may be placed at any 2 MB aligned offset in physical memory.

This is accomplished by ignoring PHYS_OFFSET when installing memblocks, and accounting for the apparent virtual offset of the kernel Image (in addition to the 64 MB that it is moved below PAGE_OFFSET). As a result, virtual address references below PAGE_OFFSET are correctly mapped onto physical references into the kernel Image regardless of where it sits in memory.

Signed-off-by Ard Biesheuvel <[email protected]>

arch/arm64/mm/mmu.c +16 -1

index 4a1c9d0769f2..675757c01eff 100644
@@ -21,6 +21,7 @@
 #include <linux/kernel.h>
 #include <linux/errno.h>
 #include <linux/init.h>
+#include <linux/initrd.h>
 #include <linux/libfdt.h>
 #include <linux/mman.h>
 #include <linux/nodemask.h>

@@ -432,11 +433,34 @@ static void __init bootstrap_linear_mapping(unsigned long va_offset)
 static void __init map_mem(void)
 {
 	struct memblock_region *reg;
+	u64 new_memstart_addr;
+	u64 new_va_offset;
 
-	bootstrap_linear_mapping(KIMAGE_OFFSET);
+	/*
+	 * Select a suitable value for the base of physical memory.
+	 * This should be equal to or below the lowest usable physical
+	 * memory address, and aligned to PUD/PMD size so that we can map
+	 * it efficiently.
+	 */
+	new_memstart_addr = round_down(memblock_start_of_DRAM(), SZ_1G);
+
+	/*
+	 * Calculate the offset between the kernel text mapping that exists
+	 * outside of the linear mapping, and its mapping in the linear region.
+	 */
+	new_va_offset = memstart_addr - new_memstart_addr;

arch/arm64/mm/built-in.o: In function `map_mem':
... arch/arm64/mm/mmu.c:458: undefined reference to `initrd_start'

if (IS_ENABLED(CONFIG_BLK_DEV_INITRD))

arch/arm64/mm/mmu.c +1 -2

-	kernel_va_offset = KIMAGE_OFFSET;
-	memstart_addr -= KIMAGE_OFFSET;
+	memstart_addr = new_memstart_addr;
 
 	/* map all the memory banks */
 	for_each_memblock(memory, reg) {

Hi Ard,

Quoted 11 lines · Ard Biesheuvel

This relaxes the kernel Image placement requirements, so that it may be placed at any 2 MB aligned offset in physical memory.

This is accomplished by ignoring PHYS_OFFSET when installing memblocks, and accounting for the apparent virtual offset of the kernel Image (in addition to the 64 MB that it is moved below PAGE_OFFSET). As a result, virtual address references below PAGE_OFFSET are correctly mapped onto physical references into the kernel Image regardless of where it sits in memory.

Signed-off-by Ard Biesheuvel <[email protected]>

[SNIP]

Quoted 33 lines

arch/arm64/mm/mmu.c +16 -1

index 4a1c9d0769f2..675757c01eff 100644
@@ -21,6 +21,7 @@
 #include <linux/kernel.h>
 #include <linux/errno.h>
 #include <linux/init.h>
+#include <linux/initrd.h>
 #include <linux/libfdt.h>
 #include <linux/mman.h>
 #include <linux/nodemask.h>

@@ -432,11 +433,34 @@ static void __init bootstrap_linear_mapping(unsigned long va_offset)
 static void __init map_mem(void)
 {
      struct memblock_region *reg;
+     u64 new_memstart_addr;
+     u64 new_va_offset;
 
-     bootstrap_linear_mapping(KIMAGE_OFFSET);
+     /*
+      * Select a suitable value for the base of physical memory.
+      * This should be equal to or below the lowest usable physical
+      * memory address, and aligned to PUD/PMD size so that we can map
+      * it efficiently.
+      */
+     new_memstart_addr = round_down(memblock_start_of_DRAM(), SZ_1G);
+
+     /*
+      * Calculate the offset between the kernel text mapping that exists
+      * outside of the linear mapping, and its mapping in the linear region.
+      */
+     new_va_offset = memstart_addr - new_memstart_addr;

arch/arm64/mm/mmu.c static void __init bootstrap_linear_mapping(unsigned long va_offset) · line 461

Quoted 10 lines

arch/arm64/mm/mmu.c +10 -0

+
+     bootstrap_linear_mapping(new_va_offset);
+
+     kernel_va_offset = new_va_offset;
+
+     /* Recalculate virtual addresses of initrd region */
+     if (initrd_start) {
+             initrd_start += new_va_offset;
+             initrd_end += new_va_offset;
+     }

This breaks the build for me, with messages like:

Quoted 2 lines

arch/arm64/mm/built-in.o: In function `map_mem':
... arch/arm64/mm/mmu.c:458: undefined reference to `initrd_start'

Wrapping the if with:

Quoted 1 line

if (IS_ENABLED(CONFIG_BLK_DEV_INITRD))

Solves the problem for me.

I will take this into account when I spin the next version (probably after 16k pages support is merged)

Quoted 2 lines · Ard Biesheuvel

I will take this into account when I spin the next version (probably after 16k pages support is merged)

I plan to merge 16K pages support in 4.4, waiting for the review to settle and I'll queue them.

BTW, have you tested these patches with KVM? We were wondering if the stage 1 hyp mapping gets confused.

Quoted 7 lines · Catalin Marinas

Quoted 2 lines · Ard Biesheuvel

I will take this into account when I spin the next version (probably after 16k pages support is merged)

I plan to merge 16K pages support in 4.4, waiting for the review to settle and I'll queue them.

Quoted 3 lines

BTW, have you tested these patches with KVM? We were wondering if the stage 1 hyp mapping gets confused.

I honestly don't remember, so consider that a 'no'. I will look into it before reposting.

This is a followup to the "arm64: update/clarify/relax Image and FDT placement rules" series I sent a while ago:
(http://article.gmane.org/gmane.linux.ports.arm.kernel/407148)

This has now been split in two series: this second series deals with the physical and virtual placement of the kernel Image.

This series updates the mapping of the kernel Image and the linear mapping of system memory to allow more freedom in the choice of placement without affecting the accessibility of system RAM below the kernel Image, and the mapping efficiency (i.e., memory can always be mapped in 512 MB or 1 GB blocks).

Quoted 9 lines · Ard Biesheuvel

This is a followup to the "arm64: update/clarify/relax Image and FDT placement
rules" series I sent a while ago:
(http://article.gmane.org/gmane.linux.ports.arm.kernel/407148)

This has now been split in two series: this second series deals with the physical and virtual placement of the kernel Image.

Quoted 7 lines

This series updates the mapping of the kernel Image and the linear mapping of
system memory to allow more freedom in the choice of placement without affecting
the accessibility of system RAM below the kernel Image, and the mapping efficiency (i.e., memory can always be mapped in 512 MB or 1 GB blocks).

Ard,

I gave your series a quick run and dumping the kernel page tables(with CONFIG_ARM64_PTDUMP)
I find this problem :

...

---[ Kernel Mapping ]---
0xffffffbffc000000-0xffffffbffc600000 6M RW x SHD AF
MEM/NORMAL *****
0xffffffbffc600000-0xffffffbffc7f5000 2004K RW x SHD AF UXN
MEM/NORMAL
0xffffffbffc7f5000-0xffffffbffc875000 512K RW NX SHD AF UXN
MEM/NORMAL
0xffffffbffc875000-0xffffffbffca00000 1580K RW x SHD AF UXN
MEM/NORMAL
---[ Linear Mapping ]---
0xffffffc000000000-0xffffffc040000000 1G RW NX SHD AF UXN
MEM/NORMAL

Note that the first mapping in the kernel doesn't have UXN set, which is a regression.
I haven't started digging into it yet, but I thought I will point it out here, in case you
already fixed it.

Note: I see that you have used CONFIG_ARM64_64K_PAGES to handle section/table mapping
(which I have tried to cleanup in 16K page size series and which is not merged yet).
We should be careful when we merge our patches, as we could miss such new cases.

Quoted 40 lines · Suzuki K. Poulose

Quoted 9 lines · Ard Biesheuvel

This is a followup to the "arm64: update/clarify/relax Image and FDT placement
rules" series I sent a while ago:
(http://article.gmane.org/gmane.linux.ports.arm.kernel/407148)

This has now been split in two series: this second series deals with the physical and virtual placement of the kernel Image.

Quoted 7 lines

This series updates the mapping of the kernel Image and the linear mapping of
system memory to allow more freedom in the choice of placement without affecting
the accessibility of system RAM below the kernel Image, and the mapping efficiency (i.e., memory can always be mapped in 512 MB or 1 GB blocks).

Ard,

I gave your series a quick run and dumping the kernel page tables(with CONFIG_ARM64_PTDUMP)
I find this problem :

...

---[ Kernel Mapping ]---
0xffffffbffc000000-0xffffffbffc600000 6M RW x SHD AF
MEM/NORMAL *****
0xffffffbffc600000-0xffffffbffc7f5000 2004K RW x SHD AF UXN
MEM/NORMAL
0xffffffbffc7f5000-0xffffffbffc875000 512K RW NX SHD AF UXN
MEM/NORMAL
0xffffffbffc875000-0xffffffbffca00000 1580K RW x SHD AF UXN
MEM/NORMAL
---[ Linear Mapping ]---
0xffffffc000000000-0xffffffc040000000 1G RW NX SHD AF UXN
MEM/NORMAL

Quoted 6 lines

Note that the first mapping in the kernel doesn't have UXN set, which is a regression.
I haven't started digging into it yet, but I thought I will point it out here, in case you
already fixed it.

Ok, thanks for pointing that out. I will look into it.

Quoted 7 lines

Note: I see that you have used CONFIG_ARM64_64K_PAGES to handle section/table mapping
(which I have tried to cleanup in 16K page size series and which is not merged yet).
We should be careful when we merge our patches, as we could miss such new cases.

I was aware of this, and I think it makes sense to the 16 KB pages to be merged first, and then I will rebase these patches on top of it.

Quoted 27 lines · Ard Biesheuvel

Quoted 26 lines · Suzuki K. Poulose

On 23/09/15 01:37, Ard Biesheuvel wrote:

Ard,

I gave your series a quick run and dumping the kernel page tables(with CONFIG_ARM64_PTDUMP)
I find this problem :

...

---[ Kernel Mapping ]---
0xffffffbffc000000-0xffffffbffc600000 6M RW x SHD AF
MEM/NORMAL *****
0xffffffbffc600000-0xffffffbffc7f5000 2004K RW x SHD AF UXN
MEM/NORMAL
0xffffffbffc7f5000-0xffffffbffc875000 512K RW NX SHD AF UXN
MEM/NORMAL
0xffffffbffc875000-0xffffffbffca00000 1580K RW x SHD AF UXN
MEM/NORMAL
---[ Linear Mapping ]---
0xffffffc000000000-0xffffffc040000000 1G RW NX SHD AF UXN
MEM/NORMAL

Quoted 9 lines

Quoted 6 lines

Note that the first mapping in the kernel doesn't have UXN set, which is a regression.
I haven't started digging into it yet, but I thought I will point it out here, in case you
already fixed it.

Ok, thanks for pointing that out. I will look into it.

Turns out that, since the kernel mapping is not overwritten by the linear mapping, it retains the original permissions assigned in head.S. So this is enough to fix it

"""

arch/arm64/kernel/head.S +2 -2

index 2df4a55f00d4..fcd250cff4bf 100644
@@ -62,8 +62,8 @@
  /*
   * Initial memory map attributes.
   */
-#define PTE_FLAGS      PTE_TYPE_PAGE | PTE_AF | PTE_SHARED
-#define PMD_FLAGS      PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S
+#define PTE_FLAGS      PTE_TYPE_PAGE | PTE_AF | PTE_SHARED | PTE_UXN
+#define PMD_FLAGS      PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S | PMD_SECT_UXN
 
  #ifdef CONFIG_ARM64_64K_PAGES
  #define MM_MMUFLAGS    PTE_ATTRINDX(MT_NORMAL) | PTE_FLAGS

"""

Quoted 9 lines

Quoted 8 lines

Note: I see that you have used CONFIG_ARM64_64K_PAGES to handle section/table mapping
(which I have tried to cleanup in 16K page size series and which is not merged yet).
We should be careful when we merge our patches, as we could miss such new cases.

Quoted 3 lines

I was aware of this, and I think it makes sense to the 16 KB pages to be merged first, and then I will rebase these patches on top of it.

Do you have a git tree with the latest version?

Quoted 68 lines · Ard Biesheuvel

Quoted 43 lines · Ard Biesheuvel

Quoted 32 lines · Suzuki K. Poulose

On 23/09/15 01:37, Ard Biesheuvel wrote:

Ard,

I gave your series a quick run and dumping the kernel page tables(with CONFIG_ARM64_PTDUMP)
I find this problem :

...

---[ Kernel Mapping ]---
0xffffffbffc000000-0xffffffbffc600000 6M RW x SHD AF
MEM/NORMAL *****
0xffffffbffc600000-0xffffffbffc7f5000 2004K RW x SHD AF
UXN
MEM/NORMAL
0xffffffbffc7f5000-0xffffffbffc875000 512K RW NX SHD AF
UXN
MEM/NORMAL
0xffffffbffc875000-0xffffffbffca00000 1580K RW x SHD AF
UXN
MEM/NORMAL
---[ Linear Mapping ]---
0xffffffc000000000-0xffffffc040000000 1G RW NX SHD AF
UXN
MEM/NORMAL

Quoted 7 lines

Note that the first mapping in the kernel doesn't have UXN set, which is a
regression.
I haven't started digging into it yet, but I thought I will point it out here, in case you
already fixed it.

Quoted 2 lines

Ok, thanks for pointing that out. I will look into it.

Turns out that, since the kernel mapping is not overwritten by the linear mapping, it retains the original permissions assigned in head.S. So this is enough to fix it

"""

arch/arm64/kernel/head.S +2 -2

index 2df4a55f00d4..fcd250cff4bf 100644
@@ -62,8 +62,8 @@
  /*
   * Initial memory map attributes.
   */
-#define PTE_FLAGS      PTE_TYPE_PAGE | PTE_AF | PTE_SHARED
-#define PMD_FLAGS      PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S
+#define PTE_FLAGS      PTE_TYPE_PAGE | PTE_AF | PTE_SHARED | PTE_UXN
+#define PMD_FLAGS      PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S |

PMD_SECT_UXN

Quoted 4 lines

#ifdef CONFIG_ARM64_64K_PAGES
#define MM_MMUFLAGS PTE_ATTRINDX(MT_NORMAL) | PTE_FLAGS
"""

Yes, that fixes it. With that I get :

---[ Kernel Mapping ]---
0xffffffbffc000000-0xffffffbffc600000 6M RW x SHD AF UXN
MEM/NORMAL
0xffffffbffc600000-0xffffffbffc7f5000 2004K RW x SHD AF UXN
MEM/NORMAL
0xffffffbffc7f5000-0xffffffbffc875000 512K RW NX SHD AF UXN
MEM/NORMAL
0xffffffbffc875000-0xffffffbffca00000 1580K RW x SHD AF UXN
MEM/NORMAL
---[ Linear Mapping ]---
0xffffffc000000000-0xffffffc080000000 2G RW NX SHD AF UXN
MEM/NORMAL
0xffffffc800000000-0xffffffc880000000 2G RW NX SHD AF UXN
MEM/NORMAL

Quoted 16 lines

Quoted 15 lines

Quoted 11 lines

Note: I see that you have used CONFIG_ARM64_64K_PAGES to handle section/table mapping
(which I have tried to cleanup in 16K page size series and which is not merged yet).
We should be careful when we merge our patches, as we could miss such new
cases.

I was aware of this, and I think it makes sense to the 16 KB pages to be merged first, and then I will rebase these patches on top of it.

Quoted 2 lines

Do you have a git tree with the latest version?

Yes, it is available here :

git://linux-arm.org/linux-skp.git 16k/v2-4.3-rc1

This is a followup to the "arm64: update/clarify/relax Image and FDT placement rules" series I sent a while ago:
(http://article.gmane.org/gmane.linux.ports.arm.kernel/407148)

This has now been split in two series: this second series deals with the physical and virtual placement of the kernel Image.

Quoted 6 lines · Ard Biesheuvel

This is a followup to the "arm64: update/clarify/relax Image and FDT placement rules" series I sent a while ago:
(http://article.gmane.org/gmane.linux.ports.arm.kernel/407148)

Quoted 2 lines

This has now been split in two series: this second series deals with the physical and virtual placement of the kernel Image.

Quick question, to refresh my memory: if this is the second series, what is the first series?

Thanks.

Signature · 1 line

Catalin