linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/3] Move kernel mapping outside the linear mapping
@ 2021-02-25  8:04 Alexandre Ghiti
  2021-02-25  8:04 ` [PATCH 1/3] riscv: Move kernel mapping outside of " Alexandre Ghiti
                   ` (3 more replies)
  0 siblings, 4 replies; 15+ messages in thread
From: Alexandre Ghiti @ 2021-02-25  8:04 UTC (permalink / raw)
  To: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Arnd Bergmann, Andrey Ryabinin, Alexander Potapenko,
	Dmitry Vyukov, linux-doc, linux-riscv, linux-kernel, kasan-dev,
	linux-arch, linux-mm
  Cc: Alexandre Ghiti

I decided to split sv48 support in small series to ease the review.

This patchset pushes the kernel mapping (modules and BPF too) to the last
4GB of the 64bit address space, this allows to:
- implement relocatable kernel (that will come later in another
  patchset) that requires to move the kernel mapping out of the linear
  mapping to avoid to copy the kernel at a different physical address.
- have a single kernel that is not relocatable (and then that avoids the
  performance penalty imposed by PIC kernel) for both sv39 and sv48.

The first patch implements this behaviour, the second patch introduces a
documentation that describes the virtual address space layout of the 64bit
kernel and the last patch is taken from my sv48 series where I simply added
the dump of the modules/kernel/BPF mapping.

I removed the Reviewed-by on the first patch since it changed enough from
last time and deserves a second look.

Alexandre Ghiti (3):
  riscv: Move kernel mapping outside of linear mapping
  Documentation: riscv: Add documentation that describes the VM layout
  riscv: Prepare ptdump for vm layout dynamic addresses

 Documentation/riscv/index.rst       |  1 +
 Documentation/riscv/vm-layout.rst   | 61 ++++++++++++++++++++++
 arch/riscv/boot/loader.lds.S        |  3 +-
 arch/riscv/include/asm/page.h       | 18 ++++++-
 arch/riscv/include/asm/pgtable.h    | 37 +++++++++----
 arch/riscv/include/asm/set_memory.h |  1 +
 arch/riscv/kernel/head.S            |  3 +-
 arch/riscv/kernel/module.c          |  6 +--
 arch/riscv/kernel/setup.c           |  3 ++
 arch/riscv/kernel/vmlinux.lds.S     |  3 +-
 arch/riscv/mm/fault.c               | 13 +++++
 arch/riscv/mm/init.c                | 81 +++++++++++++++++++++++------
 arch/riscv/mm/kasan_init.c          |  9 ++++
 arch/riscv/mm/physaddr.c            |  2 +-
 arch/riscv/mm/ptdump.c              | 67 +++++++++++++++++++-----
 15 files changed, 258 insertions(+), 50 deletions(-)
 create mode 100644 Documentation/riscv/vm-layout.rst

-- 
2.20.1



^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH 1/3] riscv: Move kernel mapping outside of linear mapping
  2021-02-25  8:04 [PATCH 0/3] Move kernel mapping outside the linear mapping Alexandre Ghiti
@ 2021-02-25  8:04 ` Alexandre Ghiti
  2021-02-25  8:04 ` [PATCH 2/3] Documentation: riscv: Add documentation that describes the VM layout Alexandre Ghiti
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 15+ messages in thread
From: Alexandre Ghiti @ 2021-02-25  8:04 UTC (permalink / raw)
  To: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Arnd Bergmann, Andrey Ryabinin, Alexander Potapenko,
	Dmitry Vyukov, linux-doc, linux-riscv, linux-kernel, kasan-dev,
	linux-arch, linux-mm
  Cc: Alexandre Ghiti

This is a preparatory patch for relocatable kernel and sv48 support.

The kernel used to be linked at PAGE_OFFSET address therefore we could use
the linear mapping for the kernel mapping. But the relocated kernel base
address will be different from PAGE_OFFSET and since in the linear mapping,
two different virtual addresses cannot point to the same physical address,
the kernel mapping needs to lie outside the linear mapping so that we don't
have to copy it at the same physical offset.

The kernel mapping is moved to the last 2GB of the address space, BPF
is now always after the kernel and modules use the 2GB memory range right
before the kernel, so BPF and modules regions do not overlap. KASLR
implementation will simply have to move the kernel in the last 2GB range
and just take care of leaving enough space for BPF.

In addition, by moving the kernel to the end of the address space, both
sv39 and sv48 kernels will be exactly the same without needing to be
relocated at runtime.

Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
---
 arch/riscv/boot/loader.lds.S        |  3 +-
 arch/riscv/include/asm/page.h       | 18 ++++++-
 arch/riscv/include/asm/pgtable.h    | 37 +++++++++----
 arch/riscv/include/asm/set_memory.h |  1 +
 arch/riscv/kernel/head.S            |  3 +-
 arch/riscv/kernel/module.c          |  6 +--
 arch/riscv/kernel/setup.c           |  3 ++
 arch/riscv/kernel/vmlinux.lds.S     |  3 +-
 arch/riscv/mm/fault.c               | 13 +++++
 arch/riscv/mm/init.c                | 81 +++++++++++++++++++++++------
 arch/riscv/mm/kasan_init.c          |  9 ++++
 arch/riscv/mm/physaddr.c            |  2 +-
 12 files changed, 141 insertions(+), 38 deletions(-)

diff --git a/arch/riscv/boot/loader.lds.S b/arch/riscv/boot/loader.lds.S
index 47a5003c2e28..62d94696a19c 100644
--- a/arch/riscv/boot/loader.lds.S
+++ b/arch/riscv/boot/loader.lds.S
@@ -1,13 +1,14 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 
 #include <asm/page.h>
+#include <asm/pgtable.h>
 
 OUTPUT_ARCH(riscv)
 ENTRY(_start)
 
 SECTIONS
 {
-	. = PAGE_OFFSET;
+	. = KERNEL_LINK_ADDR;
 
 	.payload : {
 		*(.payload)
diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h
index e49d51b97bc1..6557535dc2da 100644
--- a/arch/riscv/include/asm/page.h
+++ b/arch/riscv/include/asm/page.h
@@ -90,15 +90,29 @@ typedef struct page *pgtable_t;
 
 #ifdef CONFIG_MMU
 extern unsigned long va_pa_offset;
+extern unsigned long va_kernel_pa_offset;
 extern unsigned long pfn_base;
 #define ARCH_PFN_OFFSET		(pfn_base)
 #else
 #define va_pa_offset		0
+#define va_kernel_pa_offset	0
 #define ARCH_PFN_OFFSET		(PAGE_OFFSET >> PAGE_SHIFT)
 #endif /* CONFIG_MMU */
 
-#define __pa_to_va_nodebug(x)	((void *)((unsigned long) (x) + va_pa_offset))
-#define __va_to_pa_nodebug(x)	((unsigned long)(x) - va_pa_offset)
+extern unsigned long kernel_virt_addr;
+extern uintptr_t load_pa, load_sz, load_sz_pmd;
+
+#define linear_mapping_pa_to_va(x)	((void *)((unsigned long)(x) + va_pa_offset))
+#define __pa_to_va_nodebug(x)		linear_mapping_pa_to_va(x)
+
+#define linear_mapping_va_to_pa(x)	((unsigned long)(x) - va_pa_offset)
+#define kernel_mapping_va_to_pa(x)	\
+	((unsigned long)(x) - va_kernel_pa_offset)
+#define __va_to_pa_nodebug(x)	({						\
+	unsigned long _x = x;							\
+	(_x < kernel_virt_addr) ?						\
+		linear_mapping_va_to_pa(_x) : kernel_mapping_va_to_pa(_x);	\
+	})
 
 #ifdef CONFIG_DEBUG_VIRTUAL
 extern phys_addr_t __virt_to_phys(unsigned long x);
diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index 25e90cf0bde4..50c068993591 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -11,23 +11,30 @@
 
 #include <asm/pgtable-bits.h>
 
-#ifndef __ASSEMBLY__
-
-/* Page Upper Directory not used in RISC-V */
-#include <asm-generic/pgtable-nopud.h>
-#include <asm/page.h>
-#include <asm/tlbflush.h>
-#include <linux/mm_types.h>
+#ifndef CONFIG_MMU
+#define KERNEL_LINK_ADDR	PAGE_OFFSET
+#else
 
-#ifdef CONFIG_MMU
+#define ADDRESS_SPACE_END	(UL(-1))
+/*
+ * Leave 2GB for kernel and BPF at the end of the address space
+ */
+#define KERNEL_LINK_ADDR	(ADDRESS_SPACE_END - SZ_2G + 1)
 
 #define VMALLOC_SIZE     (KERN_VIRT_SIZE >> 1)
 #define VMALLOC_END      (PAGE_OFFSET - 1)
 #define VMALLOC_START    (PAGE_OFFSET - VMALLOC_SIZE)
 
+/* KASLR should leave at least 128MB for BPF after the kernel */
 #define BPF_JIT_REGION_SIZE	(SZ_128M)
-#define BPF_JIT_REGION_START	(PAGE_OFFSET - BPF_JIT_REGION_SIZE)
-#define BPF_JIT_REGION_END	(VMALLOC_END)
+#define BPF_JIT_REGION_START	PFN_ALIGN((unsigned long)&_end)
+#define BPF_JIT_REGION_END	(BPF_JIT_REGION_START + BPF_JIT_REGION_SIZE)
+
+/* Modules always live before the kernel */
+#ifdef CONFIG_64BIT
+#define MODULES_VADDR	(PFN_ALIGN((unsigned long)&_end) - SZ_2G)
+#define MODULES_END	(PFN_ALIGN((unsigned long)&_start))
+#endif
 
 /*
  * Roughly size the vmemmap space to be large enough to fit enough
@@ -57,9 +64,16 @@
 #define FIXADDR_SIZE     PGDIR_SIZE
 #endif
 #define FIXADDR_START    (FIXADDR_TOP - FIXADDR_SIZE)
-
 #endif
 
+#ifndef __ASSEMBLY__
+
+/* Page Upper Directory not used in RISC-V */
+#include <asm-generic/pgtable-nopud.h>
+#include <asm/page.h>
+#include <asm/tlbflush.h>
+#include <linux/mm_types.h>
+
 #ifdef CONFIG_64BIT
 #include <asm/pgtable-64.h>
 #else
@@ -485,6 +499,7 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
 
 #define kern_addr_valid(addr)   (1) /* FIXME */
 
+extern char _start[];
 extern void *dtb_early_va;
 extern uintptr_t dtb_early_pa;
 void setup_bootmem(void);
diff --git a/arch/riscv/include/asm/set_memory.h b/arch/riscv/include/asm/set_memory.h
index 9fa510707012..03df05bc639a 100644
--- a/arch/riscv/include/asm/set_memory.h
+++ b/arch/riscv/include/asm/set_memory.h
@@ -17,6 +17,7 @@ int set_memory_x(unsigned long addr, int numpages);
 int set_memory_nx(unsigned long addr, int numpages);
 int set_memory_rw_nx(unsigned long addr, int numpages);
 void protect_kernel_text_data(void);
+void protect_kernel_linear_mapping_text_rodata(void);
 #else
 static inline int set_memory_ro(unsigned long addr, int numpages) { return 0; }
 static inline int set_memory_rw(unsigned long addr, int numpages) { return 0; }
diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
index f5a9bad86e58..6cb05f22e52a 100644
--- a/arch/riscv/kernel/head.S
+++ b/arch/riscv/kernel/head.S
@@ -69,7 +69,8 @@ pe_head_start:
 #ifdef CONFIG_MMU
 relocate:
 	/* Relocate return address */
-	li a1, PAGE_OFFSET
+	la a1, kernel_virt_addr
+	REG_L a1, 0(a1)
 	la a2, _start
 	sub a1, a1, a2
 	add ra, ra, a1
diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
index 104fba889cf7..ce153771e5e9 100644
--- a/arch/riscv/kernel/module.c
+++ b/arch/riscv/kernel/module.c
@@ -408,12 +408,10 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
 }
 
 #if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
-#define VMALLOC_MODULE_START \
-	 max(PFN_ALIGN((unsigned long)&_end - SZ_2G), VMALLOC_START)
 void *module_alloc(unsigned long size)
 {
-	return __vmalloc_node_range(size, 1, VMALLOC_MODULE_START,
-				    VMALLOC_END, GFP_KERNEL,
+	return __vmalloc_node_range(size, 1, MODULES_VADDR,
+				    MODULES_END, GFP_KERNEL,
 				    PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
 				    __builtin_return_address(0));
 }
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 4945b5085241..c8ea6a72faf6 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -263,6 +263,9 @@ void __init setup_arch(char **cmdline_p)
 
 	if (IS_ENABLED(CONFIG_STRICT_KERNEL_RWX))
 		protect_kernel_text_data();
+
+	protect_kernel_linear_mapping_text_rodata();
+
 #ifdef CONFIG_SWIOTLB
 	swiotlb_init(1);
 #endif
diff --git a/arch/riscv/kernel/vmlinux.lds.S b/arch/riscv/kernel/vmlinux.lds.S
index de03cb22d0e9..0726c05e0336 100644
--- a/arch/riscv/kernel/vmlinux.lds.S
+++ b/arch/riscv/kernel/vmlinux.lds.S
@@ -4,7 +4,8 @@
  * Copyright (C) 2017 SiFive
  */
 
-#define LOAD_OFFSET PAGE_OFFSET
+#include <asm/pgtable.h>
+#define LOAD_OFFSET KERNEL_LINK_ADDR
 #include <asm/vmlinux.lds.h>
 #include <asm/page.h>
 #include <asm/cache.h>
diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
index 8f17519208c7..1b14d523a95c 100644
--- a/arch/riscv/mm/fault.c
+++ b/arch/riscv/mm/fault.c
@@ -231,6 +231,19 @@ asmlinkage void do_page_fault(struct pt_regs *regs)
 		return;
 	}
 
+#ifdef CONFIG_64BIT
+	/*
+	 * Modules in 64bit kernels lie in their own virtual region which is not
+	 * in the vmalloc region, but dealing with page faults in this region
+	 * or the vmalloc region amounts to doing the same thing: checking that
+	 * the mapping exists in init_mm.pgd and updating user page table, so
+	 * just use vmalloc_fault.
+	 */
+	if (unlikely(addr >= MODULES_VADDR && addr < MODULES_END)) {
+		vmalloc_fault(regs, code, addr);
+		return;
+	}
+#endif
 	/* Enable interrupts if they were enabled in the parent context. */
 	if (likely(regs->status & SR_PIE))
 		local_irq_enable();
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 3e044f11cef6..18792937cf31 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -25,6 +25,9 @@
 
 #include "../kernel/head.h"
 
+unsigned long kernel_virt_addr = KERNEL_LINK_ADDR;
+EXPORT_SYMBOL(kernel_virt_addr);
+
 unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)]
 							__page_aligned_bss;
 EXPORT_SYMBOL(empty_zero_page);
@@ -88,6 +91,8 @@ static void print_vm_layout(void)
 		  (unsigned long)VMALLOC_END);
 	print_mlm("lowmem", (unsigned long)PAGE_OFFSET,
 		  (unsigned long)high_memory);
+	print_mlm("kernel", (unsigned long)KERNEL_LINK_ADDR,
+		  (unsigned long)ADDRESS_SPACE_END);
 }
 #else
 static void print_vm_layout(void) { }
@@ -130,8 +135,13 @@ void __init setup_bootmem(void)
 	 */
 	memblock_enforce_memory_limit(-PAGE_OFFSET);
 
-	/* Reserve from the start of the kernel to the end of the kernel */
-	memblock_reserve(vmlinux_start, vmlinux_end - vmlinux_start);
+	/*
+	 * Reserve from the start of the kernel to the end of the kernel
+	 * and make sure we align the reservation on PMD_SIZE since we will
+	 * map the kernel in the linear mapping as read-only: we do not want
+	 * any allocation to happen between _end and the next pmd aligned page.
+	 */
+	memblock_reserve(load_pa, load_sz_pmd);
 
 	max_pfn = PFN_DOWN(memblock_end_of_DRAM());
 	max_low_pfn = max_pfn;
@@ -156,8 +166,12 @@ void __init setup_bootmem(void)
 #ifdef CONFIG_MMU
 static struct pt_alloc_ops pt_ops;
 
+/* Offset between linear mapping virtual address and kernel load address */
 unsigned long va_pa_offset;
 EXPORT_SYMBOL(va_pa_offset);
+/* Offset between kernel mapping virtual address and kernel load address */
+unsigned long va_kernel_pa_offset;
+EXPORT_SYMBOL(va_kernel_pa_offset);
 unsigned long pfn_base;
 EXPORT_SYMBOL(pfn_base);
 
@@ -261,7 +275,7 @@ static pmd_t *get_pmd_virt_late(phys_addr_t pa)
 
 static phys_addr_t __init alloc_pmd_early(uintptr_t va)
 {
-	BUG_ON((va - PAGE_OFFSET) >> PGDIR_SHIFT);
+	BUG_ON((va - kernel_virt_addr) >> PGDIR_SHIFT);
 
 	return (uintptr_t)early_pmd;
 }
@@ -376,17 +390,37 @@ static uintptr_t __init best_map_size(phys_addr_t base, phys_addr_t size)
 #error "setup_vm() is called from head.S before relocate so it should not use absolute addressing."
 #endif
 
+uintptr_t load_pa, load_sz, load_sz_pmd;
+EXPORT_SYMBOL(load_pa);
+EXPORT_SYMBOL(load_sz);
+EXPORT_SYMBOL(load_sz_pmd);
+
+static void __init create_kernel_page_table(pgd_t *pgdir, uintptr_t map_size)
+{
+	uintptr_t va, end_va;
+
+	end_va = kernel_virt_addr + load_sz;
+	for (va = kernel_virt_addr; va < end_va; va += map_size)
+		create_pgd_mapping(pgdir, va,
+				   load_pa + (va - kernel_virt_addr),
+				   map_size, PAGE_KERNEL_EXEC);
+}
+
 asmlinkage void __init setup_vm(uintptr_t dtb_pa)
 {
-	uintptr_t va, pa, end_va;
-	uintptr_t load_pa = (uintptr_t)(&_start);
-	uintptr_t load_sz = (uintptr_t)(&_end) - load_pa;
+	uintptr_t pa;
 	uintptr_t map_size;
 #ifndef __PAGETABLE_PMD_FOLDED
 	pmd_t fix_bmap_spmd, fix_bmap_epmd;
 #endif
 
+	load_pa = (uintptr_t)(&_start);
+	load_sz = (uintptr_t)(&_end) - load_pa;
+	load_sz_pmd = (load_sz + PMD_SIZE - 1) & PMD_MASK;
+
 	va_pa_offset = PAGE_OFFSET - load_pa;
+	va_kernel_pa_offset = kernel_virt_addr - load_pa;
+
 	pfn_base = PFN_DOWN(load_pa);
 
 	/*
@@ -414,26 +448,22 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)
 	create_pmd_mapping(fixmap_pmd, FIXADDR_START,
 			   (uintptr_t)fixmap_pte, PMD_SIZE, PAGE_TABLE);
 	/* Setup trampoline PGD and PMD */
-	create_pgd_mapping(trampoline_pg_dir, PAGE_OFFSET,
+	create_pgd_mapping(trampoline_pg_dir, kernel_virt_addr,
 			   (uintptr_t)trampoline_pmd, PGDIR_SIZE, PAGE_TABLE);
-	create_pmd_mapping(trampoline_pmd, PAGE_OFFSET,
+	create_pmd_mapping(trampoline_pmd, kernel_virt_addr,
 			   load_pa, PMD_SIZE, PAGE_KERNEL_EXEC);
 #else
 	/* Setup trampoline PGD */
-	create_pgd_mapping(trampoline_pg_dir, PAGE_OFFSET,
+	create_pgd_mapping(trampoline_pg_dir, kernel_virt_addr,
 			   load_pa, PGDIR_SIZE, PAGE_KERNEL_EXEC);
 #endif
 
 	/*
-	 * Setup early PGD covering entire kernel which will allows
+	 * Setup early PGD covering entire kernel which will allow
 	 * us to reach paging_init(). We map all memory banks later
 	 * in setup_vm_final() below.
 	 */
-	end_va = PAGE_OFFSET + load_sz;
-	for (va = PAGE_OFFSET; va < end_va; va += map_size)
-		create_pgd_mapping(early_pg_dir, va,
-				   load_pa + (va - PAGE_OFFSET),
-				   map_size, PAGE_KERNEL_EXEC);
+	create_kernel_page_table(early_pg_dir, map_size);
 
 #ifndef __PAGETABLE_PMD_FOLDED
 	/* Setup early PMD for DTB */
@@ -496,6 +526,20 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)
 #endif
 }
 
+void protect_kernel_linear_mapping_text_rodata(void)
+{
+	unsigned long text_start = (unsigned long)lm_alias(_start);
+	unsigned long init_text_start = (unsigned long)lm_alias(__init_text_begin);
+	unsigned long rodata_start = (unsigned long)lm_alias(__start_rodata);
+	unsigned long data_start = (unsigned long)lm_alias(_data);
+
+	set_memory_ro(text_start, (init_text_start - text_start) >> PAGE_SHIFT);
+	set_memory_nx(text_start, (init_text_start - text_start) >> PAGE_SHIFT);
+
+	set_memory_ro(rodata_start, (data_start - rodata_start) >> PAGE_SHIFT);
+	set_memory_nx(rodata_start, (data_start - rodata_start) >> PAGE_SHIFT);
+}
+
 static void __init setup_vm_final(void)
 {
 	uintptr_t va, map_size;
@@ -517,7 +561,7 @@ static void __init setup_vm_final(void)
 			   __pa_symbol(fixmap_pgd_next),
 			   PGDIR_SIZE, PAGE_TABLE);
 
-	/* Map all memory banks */
+	/* Map all memory banks in the linear mapping */
 	for_each_mem_range(i, &start, &end) {
 		if (start >= end)
 			break;
@@ -529,10 +573,13 @@ static void __init setup_vm_final(void)
 		for (pa = start; pa < end; pa += map_size) {
 			va = (uintptr_t)__va(pa);
 			create_pgd_mapping(swapper_pg_dir, va, pa,
-					   map_size, PAGE_KERNEL_EXEC);
+					   map_size, PAGE_KERNEL);
 		}
 	}
 
+	/* Map the kernel */
+	create_kernel_page_table(swapper_pg_dir, PMD_SIZE);
+
 	/* Clear fixmap PTE and PMD mappings */
 	clear_fixmap(FIX_PTE);
 	clear_fixmap(FIX_PMD);
diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index 171569df4334..89622785d500 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -172,6 +172,10 @@ void __init kasan_init(void)
 	phys_addr_t _start, _end;
 	u64 i;
 
+	/*
+	 * Populate all kernel virtual address space with kasan_early_shadow_page
+	 * except for the linear mapping and the modules/kernel/BPF mapping.
+	 */
 	kasan_populate_early_shadow((void *)KASAN_SHADOW_START,
 				    (void *)kasan_mem_to_shadow((void *)
 								VMEMMAP_END));
@@ -184,6 +188,7 @@ void __init kasan_init(void)
 			(void *)kasan_mem_to_shadow((void *)VMALLOC_START),
 			(void *)kasan_mem_to_shadow((void *)VMALLOC_END));
 
+	/* Populate the linear mapping */
 	for_each_mem_range(i, &_start, &_end) {
 		void *start = (void *)_start;
 		void *end = (void *)_end;
@@ -194,6 +199,10 @@ void __init kasan_init(void)
 		kasan_populate(kasan_mem_to_shadow(start), kasan_mem_to_shadow(end));
 	};
 
+	/* Populate kernel, BPF, modules mapping */
+	kasan_populate(kasan_mem_to_shadow((const void *)MODULES_VADDR),
+		       kasan_mem_to_shadow((const void *)BPF_JIT_REGION_END));
+
 	for (i = 0; i < PTRS_PER_PTE; i++)
 		set_pte(&kasan_early_shadow_pte[i],
 			mk_pte(virt_to_page(kasan_early_shadow_page),
diff --git a/arch/riscv/mm/physaddr.c b/arch/riscv/mm/physaddr.c
index e8e4dcd39fed..35703d5ef5fd 100644
--- a/arch/riscv/mm/physaddr.c
+++ b/arch/riscv/mm/physaddr.c
@@ -23,7 +23,7 @@ EXPORT_SYMBOL(__virt_to_phys);
 
 phys_addr_t __phys_addr_symbol(unsigned long x)
 {
-	unsigned long kernel_start = (unsigned long)PAGE_OFFSET;
+	unsigned long kernel_start = (unsigned long)kernel_virt_addr;
 	unsigned long kernel_end = (unsigned long)_end;
 
 	/*
-- 
2.20.1



^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [PATCH 2/3] Documentation: riscv: Add documentation that describes the VM layout
  2021-02-25  8:04 [PATCH 0/3] Move kernel mapping outside the linear mapping Alexandre Ghiti
  2021-02-25  8:04 ` [PATCH 1/3] riscv: Move kernel mapping outside of " Alexandre Ghiti
@ 2021-02-25  8:04 ` Alexandre Ghiti
  2021-02-25 10:34   ` David Hildenbrand
  2021-02-25  8:04 ` [PATCH 3/3] riscv: Prepare ptdump for vm layout dynamic addresses Alexandre Ghiti
  2021-03-10  2:54 ` [PATCH 0/3] Move kernel mapping outside the linear mapping Palmer Dabbelt
  3 siblings, 1 reply; 15+ messages in thread
From: Alexandre Ghiti @ 2021-02-25  8:04 UTC (permalink / raw)
  To: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Arnd Bergmann, Andrey Ryabinin, Alexander Potapenko,
	Dmitry Vyukov, linux-doc, linux-riscv, linux-kernel, kasan-dev,
	linux-arch, linux-mm
  Cc: Alexandre Ghiti

This new document presents the RISC-V virtual memory layout and is based
one the x86 one: it describes the different limits of the different regions
of the virtual address space.

Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
---
 Documentation/riscv/index.rst     |  1 +
 Documentation/riscv/vm-layout.rst | 61 +++++++++++++++++++++++++++++++
 2 files changed, 62 insertions(+)
 create mode 100644 Documentation/riscv/vm-layout.rst

diff --git a/Documentation/riscv/index.rst b/Documentation/riscv/index.rst
index 6e6e39482502..ea915c196048 100644
--- a/Documentation/riscv/index.rst
+++ b/Documentation/riscv/index.rst
@@ -6,6 +6,7 @@ RISC-V architecture
     :maxdepth: 1
 
     boot-image-header
+    vm-layout
     pmu
     patch-acceptance
 
diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst
new file mode 100644
index 000000000000..e8e569e2686a
--- /dev/null
+++ b/Documentation/riscv/vm-layout.rst
@@ -0,0 +1,61 @@
+=====================================
+Virtual Memory Layout on RISC-V Linux
+=====================================
+
+:Author: Alexandre Ghiti <alex@ghiti.fr>
+:Date: 12 February 2021
+
+This document describes the virtual memory layout used by the RISC-V Linux
+Kernel.
+
+RISC-V Linux Kernel 32bit
+=========================
+
+RISC-V Linux Kernel SV32
+------------------------
+
+TODO
+
+RISC-V Linux Kernel 64bit
+=========================
+
+The RISC-V privileged architecture document states that the 64bit addresses
+"must have bits 63–48 all equal to bit 47, or else a page-fault exception will
+occur.": that splits the virtual address space into 2 halves separated by a very
+big hole, the lower half is where the userspace resides, the upper half is where
+the RISC-V Linux Kernel resides.
+
+RISC-V Linux Kernel SV39
+------------------------
+
+::
+
+  ========================================================================================================================
+      Start addr    |   Offset   |     End addr     |  Size   | VM area description
+  ========================================================================================================================
+                    |            |                  |         |
+   0000000000000000 |    0       | 0000003fffffffff |  256 GB | user-space virtual memory, different per mm
+  __________________|____________|__________________|_________|___________________________________________________________
+                    |            |                  |         |
+   0000004000000000 | +256    GB | ffffffbfffffffff | ~16M TB | ... huge, almost 64 bits wide hole of non-canonical
+                    |            |                  |         |     virtual memory addresses up to the -256 GB
+                    |            |                  |         |     starting offset of kernel mappings.
+  __________________|____________|__________________|_________|___________________________________________________________
+                                                              |
+                                                              | Kernel-space virtual memory, shared between all processes:
+  ____________________________________________________________|___________________________________________________________
+                    |            |                  |         |
+   ffffffc000000000 | -256    GB | ffffffc7ffffffff |   32 GB | kasan
+   ffffffcefee00000 | -196    GB | ffffffcefeffffff |    2 MB | fixmap
+   ffffffceff000000 | -196    GB | ffffffceffffffff |   16 MB | PCI io
+   ffffffcf00000000 | -196    GB | ffffffcfffffffff |    4 GB | vmemmap
+   ffffffd000000000 | -192    GB | ffffffdfffffffff |   64 GB | vmalloc/ioremap space
+   ffffffe000000000 | -128    GB | ffffffff7fffffff |  126 GB | direct mapping of all physical memory
+  __________________|____________|__________________|_________|____________________________________________________________
+                                                              |
+                                                              |
+  ____________________________________________________________|____________________________________________________________
+                    |            |                  |         |
+   ffffffff00000000 |   -4    GB | ffffffff7fffffff |    2 GB | modules
+   ffffffff80000000 |   -2    GB | ffffffffffffffff |    2 GB | kernel, BPF
+  __________________|____________|__________________|_________|____________________________________________________________
-- 
2.20.1



^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [PATCH 3/3] riscv: Prepare ptdump for vm layout dynamic addresses
  2021-02-25  8:04 [PATCH 0/3] Move kernel mapping outside the linear mapping Alexandre Ghiti
  2021-02-25  8:04 ` [PATCH 1/3] riscv: Move kernel mapping outside of " Alexandre Ghiti
  2021-02-25  8:04 ` [PATCH 2/3] Documentation: riscv: Add documentation that describes the VM layout Alexandre Ghiti
@ 2021-02-25  8:04 ` Alexandre Ghiti
  2021-03-10  2:54 ` [PATCH 0/3] Move kernel mapping outside the linear mapping Palmer Dabbelt
  3 siblings, 0 replies; 15+ messages in thread
From: Alexandre Ghiti @ 2021-02-25  8:04 UTC (permalink / raw)
  To: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Arnd Bergmann, Andrey Ryabinin, Alexander Potapenko,
	Dmitry Vyukov, linux-doc, linux-riscv, linux-kernel, kasan-dev,
	linux-arch, linux-mm
  Cc: Alexandre Ghiti, Anup Patel

This is a preparatory patch for sv48 support that will introduce
dynamic PAGE_OFFSET.

Dynamic PAGE_OFFSET implies that all zones (vmalloc, vmemmap, fixaddr...)
whose addresses depend on PAGE_OFFSET become dynamic and can't be used
to statically initialize the array used by ptdump to identify the
different zones of the vm layout.

Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
Reviewed-by: Anup Patel <anup@brainfault.org>
---
 arch/riscv/mm/ptdump.c | 67 ++++++++++++++++++++++++++++++++++--------
 1 file changed, 55 insertions(+), 12 deletions(-)

diff --git a/arch/riscv/mm/ptdump.c b/arch/riscv/mm/ptdump.c
index ace74dec7492..aa1b3bce61ab 100644
--- a/arch/riscv/mm/ptdump.c
+++ b/arch/riscv/mm/ptdump.c
@@ -58,29 +58,52 @@ struct ptd_mm_info {
 	unsigned long end;
 };
 
+enum address_markers_idx {
+#ifdef CONFIG_KASAN
+	KASAN_SHADOW_START_NR,
+	KASAN_SHADOW_END_NR,
+#endif
+	FIXMAP_START_NR,
+	FIXMAP_END_NR,
+	PCI_IO_START_NR,
+	PCI_IO_END_NR,
+#ifdef CONFIG_SPARSEMEM_VMEMMAP
+	VMEMMAP_START_NR,
+	VMEMMAP_END_NR,
+#endif
+	VMALLOC_START_NR,
+	VMALLOC_END_NR,
+	PAGE_OFFSET_NR,
+	MODULES_MAPPING_NR,
+	KERNEL_MAPPING_NR,
+	END_OF_SPACE_NR
+};
+
 static struct addr_marker address_markers[] = {
 #ifdef CONFIG_KASAN
-	{KASAN_SHADOW_START,	"Kasan shadow start"},
-	{KASAN_SHADOW_END,	"Kasan shadow end"},
+	{0, "Kasan shadow start"},
+	{0, "Kasan shadow end"},
 #endif
-	{FIXADDR_START,		"Fixmap start"},
-	{FIXADDR_TOP,		"Fixmap end"},
-	{PCI_IO_START,		"PCI I/O start"},
-	{PCI_IO_END,		"PCI I/O end"},
+	{0, "Fixmap start"},
+	{0, "Fixmap end"},
+	{0, "PCI I/O start"},
+	{0, "PCI I/O end"},
 #ifdef CONFIG_SPARSEMEM_VMEMMAP
-	{VMEMMAP_START,		"vmemmap start"},
-	{VMEMMAP_END,		"vmemmap end"},
+	{0, "vmemmap start"},
+	{0, "vmemmap end"},
 #endif
-	{VMALLOC_START,		"vmalloc() area"},
-	{VMALLOC_END,		"vmalloc() end"},
-	{PAGE_OFFSET,		"Linear mapping"},
+	{0, "vmalloc() area"},
+	{0, "vmalloc() end"},
+	{0, "Linear mapping"},
+	{0, "Modules mapping"},
+	{0, "Kernel mapping (kernel, BPF)"},
 	{-1, NULL},
 };
 
 static struct ptd_mm_info kernel_ptd_info = {
 	.mm		= &init_mm,
 	.markers	= address_markers,
-	.base_addr	= KERN_VIRT_START,
+	.base_addr	= 0,
 	.end		= ULONG_MAX,
 };
 
@@ -335,6 +358,26 @@ static int ptdump_init(void)
 {
 	unsigned int i, j;
 
+#ifdef CONFIG_KASAN
+	address_markers[KASAN_SHADOW_START_NR].start_address = KASAN_SHADOW_START;
+	address_markers[KASAN_SHADOW_END_NR].start_address = KASAN_SHADOW_END;
+#endif
+	address_markers[FIXMAP_START_NR].start_address = FIXADDR_START;
+	address_markers[FIXMAP_END_NR].start_address = FIXADDR_TOP;
+	address_markers[PCI_IO_START_NR].start_address = PCI_IO_START;
+	address_markers[PCI_IO_END_NR].start_address = PCI_IO_END;
+#ifdef CONFIG_SPARSEMEM_VMEMMAP
+	address_markers[VMEMMAP_START_NR].start_address = VMEMMAP_START;
+	address_markers[VMEMMAP_END_NR].start_address = VMEMMAP_END;
+#endif
+	address_markers[VMALLOC_START_NR].start_address = VMALLOC_START;
+	address_markers[VMALLOC_END_NR].start_address = VMALLOC_END;
+	address_markers[PAGE_OFFSET_NR].start_address = PAGE_OFFSET;
+	address_markers[MODULES_MAPPING_NR].start_address = MODULES_VADDR;
+	address_markers[KERNEL_MAPPING_NR].start_address = kernel_virt_addr;
+
+	kernel_ptd_info.base_addr = KERN_VIRT_START;
+
 	for (i = 0; i < ARRAY_SIZE(pg_level); i++)
 		for (j = 0; j < ARRAY_SIZE(pte_bits); j++)
 			pg_level[i].mask |= pte_bits[j].mask;
-- 
2.20.1



^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [PATCH 2/3] Documentation: riscv: Add documentation that describes the VM layout
  2021-02-25  8:04 ` [PATCH 2/3] Documentation: riscv: Add documentation that describes the VM layout Alexandre Ghiti
@ 2021-02-25 10:34   ` David Hildenbrand
  2021-02-25 11:56     ` Alex Ghiti
  0 siblings, 1 reply; 15+ messages in thread
From: David Hildenbrand @ 2021-02-25 10:34 UTC (permalink / raw)
  To: Alexandre Ghiti, Jonathan Corbet, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Arnd Bergmann, Andrey Ryabinin, Alexander Potapenko,
	Dmitry Vyukov, linux-doc, linux-riscv, linux-kernel, kasan-dev,
	linux-arch, linux-mm

                  |            |                  |         |> + 
ffffffc000000000 | -256    GB | ffffffc7ffffffff |   32 GB | kasan
> +   ffffffcefee00000 | -196    GB | ffffffcefeffffff |    2 MB | fixmap
> +   ffffffceff000000 | -196    GB | ffffffceffffffff |   16 MB | PCI io
> +   ffffffcf00000000 | -196    GB | ffffffcfffffffff |    4 GB | vmemmap
> +   ffffffd000000000 | -192    GB | ffffffdfffffffff |   64 GB | vmalloc/ioremap space
> +   ffffffe000000000 | -128    GB | ffffffff7fffffff |  126 GB | direct mapping of all physical memory

^ So you could never ever have more than 126 GB, correct?

I assume that's nothing new.

-- 
Thanks,

David / dhildenb



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 2/3] Documentation: riscv: Add documentation that describes the VM layout
  2021-02-25 10:34   ` David Hildenbrand
@ 2021-02-25 11:56     ` Alex Ghiti
  2021-03-10 11:42       ` Arnd Bergmann
  0 siblings, 1 reply; 15+ messages in thread
From: Alex Ghiti @ 2021-02-25 11:56 UTC (permalink / raw)
  To: David Hildenbrand, Jonathan Corbet, Paul Walmsley,
	Palmer Dabbelt, Albert Ou, Arnd Bergmann, Andrey Ryabinin,
	Alexander Potapenko, Dmitry Vyukov, linux-doc, linux-riscv,
	linux-kernel, kasan-dev, linux-arch, linux-mm

Le 2/25/21 à 5:34 AM, David Hildenbrand a écrit :
>                   |            |                  |         |> + 
> ffffffc000000000 | -256    GB | ffffffc7ffffffff |   32 GB | kasan
>> +   ffffffcefee00000 | -196    GB | ffffffcefeffffff |    2 MB | fixmap
>> +   ffffffceff000000 | -196    GB | ffffffceffffffff |   16 MB | PCI io
>> +   ffffffcf00000000 | -196    GB | ffffffcfffffffff |    4 GB | vmemmap
>> +   ffffffd000000000 | -192    GB | ffffffdfffffffff |   64 GB | 
>> vmalloc/ioremap space
>> +   ffffffe000000000 | -128    GB | ffffffff7fffffff |  126 GB | 
>> direct mapping of all physical memory
> 
> ^ So you could never ever have more than 126 GB, correct?
> 
> I assume that's nothing new.
> 

Before this patch, the limit was 128GB, so in my sense, there is nothing 
new. If ever we want to increase that limit, we'll just have to lower 
PAGE_OFFSET, there is still some unused virtual addresses after kasan 
for example.

Thanks,

Alex


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/3] Move kernel mapping outside the linear mapping
  2021-02-25  8:04 [PATCH 0/3] Move kernel mapping outside the linear mapping Alexandre Ghiti
                   ` (2 preceding siblings ...)
  2021-02-25  8:04 ` [PATCH 3/3] riscv: Prepare ptdump for vm layout dynamic addresses Alexandre Ghiti
@ 2021-03-10  2:54 ` Palmer Dabbelt
  2021-03-13  9:26   ` Alex Ghiti
  2021-03-20  8:48   ` Alex Ghiti
  3 siblings, 2 replies; 15+ messages in thread
From: Palmer Dabbelt @ 2021-03-10  2:54 UTC (permalink / raw)
  To: alex
  Cc: corbet, Paul Walmsley, aou, Arnd Bergmann, aryabinin, glider,
	dvyukov, linux-doc, linux-riscv, linux-kernel, kasan-dev,
	linux-arch, linux-mm, alex

On Thu, 25 Feb 2021 00:04:50 PST (-0800), alex@ghiti.fr wrote:
> I decided to split sv48 support in small series to ease the review.
>
> This patchset pushes the kernel mapping (modules and BPF too) to the last
> 4GB of the 64bit address space, this allows to:
> - implement relocatable kernel (that will come later in another
>   patchset) that requires to move the kernel mapping out of the linear
>   mapping to avoid to copy the kernel at a different physical address.
> - have a single kernel that is not relocatable (and then that avoids the
>   performance penalty imposed by PIC kernel) for both sv39 and sv48.
>
> The first patch implements this behaviour, the second patch introduces a
> documentation that describes the virtual address space layout of the 64bit
> kernel and the last patch is taken from my sv48 series where I simply added
> the dump of the modules/kernel/BPF mapping.
>
> I removed the Reviewed-by on the first patch since it changed enough from
> last time and deserves a second look.
>
> Alexandre Ghiti (3):
>   riscv: Move kernel mapping outside of linear mapping
>   Documentation: riscv: Add documentation that describes the VM layout
>   riscv: Prepare ptdump for vm layout dynamic addresses
>
>  Documentation/riscv/index.rst       |  1 +
>  Documentation/riscv/vm-layout.rst   | 61 ++++++++++++++++++++++
>  arch/riscv/boot/loader.lds.S        |  3 +-
>  arch/riscv/include/asm/page.h       | 18 ++++++-
>  arch/riscv/include/asm/pgtable.h    | 37 +++++++++----
>  arch/riscv/include/asm/set_memory.h |  1 +
>  arch/riscv/kernel/head.S            |  3 +-
>  arch/riscv/kernel/module.c          |  6 +--
>  arch/riscv/kernel/setup.c           |  3 ++
>  arch/riscv/kernel/vmlinux.lds.S     |  3 +-
>  arch/riscv/mm/fault.c               | 13 +++++
>  arch/riscv/mm/init.c                | 81 +++++++++++++++++++++++------
>  arch/riscv/mm/kasan_init.c          |  9 ++++
>  arch/riscv/mm/physaddr.c            |  2 +-
>  arch/riscv/mm/ptdump.c              | 67 +++++++++++++++++++-----
>  15 files changed, 258 insertions(+), 50 deletions(-)
>  create mode 100644 Documentation/riscv/vm-layout.rst

This generally looks good, but I'm getting a bunch of checkpatch warnings and 
some conflicts, do you mind fixing those up (and including your other kasan 
patch, as that's likely to conflict)?


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 2/3] Documentation: riscv: Add documentation that describes the VM layout
  2021-02-25 11:56     ` Alex Ghiti
@ 2021-03-10 11:42       ` Arnd Bergmann
  2021-03-10 19:12         ` Alex Ghiti
  0 siblings, 1 reply; 15+ messages in thread
From: Arnd Bergmann @ 2021-03-10 11:42 UTC (permalink / raw)
  To: Alex Ghiti
  Cc: David Hildenbrand, Jonathan Corbet, Paul Walmsley,
	Palmer Dabbelt, Albert Ou, Andrey Ryabinin, Alexander Potapenko,
	Dmitry Vyukov, open list:DOCUMENTATION, linux-riscv,
	linux-kernel, kasan-dev, linux-arch, Linux-MM, Linus Walleij

On Thu, Feb 25, 2021 at 12:56 PM Alex Ghiti <alex@ghiti.fr> wrote:
>
> Le 2/25/21 à 5:34 AM, David Hildenbrand a écrit :
> >                   |            |                  |         |> +
> > ffffffc000000000 | -256    GB | ffffffc7ffffffff |   32 GB | kasan
> >> +   ffffffcefee00000 | -196    GB | ffffffcefeffffff |    2 MB | fixmap
> >> +   ffffffceff000000 | -196    GB | ffffffceffffffff |   16 MB | PCI io
> >> +   ffffffcf00000000 | -196    GB | ffffffcfffffffff |    4 GB | vmemmap
> >> +   ffffffd000000000 | -192    GB | ffffffdfffffffff |   64 GB |
> >> vmalloc/ioremap space
> >> +   ffffffe000000000 | -128    GB | ffffffff7fffffff |  126 GB |
> >> direct mapping of all physical memory
> >
> > ^ So you could never ever have more than 126 GB, correct?
> >
> > I assume that's nothing new.
> >
>
> Before this patch, the limit was 128GB, so in my sense, there is nothing
> new. If ever we want to increase that limit, we'll just have to lower
> PAGE_OFFSET, there is still some unused virtual addresses after kasan
> for example.

Linus Walleij is looking into changing the arm32 code to have the kernel
direct map inside of the vmalloc area, which would be another place
that you could use here. It would be nice to not have too many different
ways of doing this, but I'm not sure how hard it would be to rework your
code, or if there are any downsides of doing this.

        Arnd


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 2/3] Documentation: riscv: Add documentation that describes the VM layout
  2021-03-10 11:42       ` Arnd Bergmann
@ 2021-03-10 19:12         ` Alex Ghiti
  2021-03-11  8:42           ` Arnd Bergmann
  0 siblings, 1 reply; 15+ messages in thread
From: Alex Ghiti @ 2021-03-10 19:12 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: David Hildenbrand, Jonathan Corbet, Paul Walmsley,
	Palmer Dabbelt, Albert Ou, Andrey Ryabinin, Alexander Potapenko,
	Dmitry Vyukov, open list:DOCUMENTATION, linux-riscv,
	linux-kernel, kasan-dev, linux-arch, Linux-MM, Linus Walleij

Hi Arnd,

Le 3/10/21 à 6:42 AM, Arnd Bergmann a écrit :
> On Thu, Feb 25, 2021 at 12:56 PM Alex Ghiti <alex@ghiti.fr> wrote:
>>
>> Le 2/25/21 à 5:34 AM, David Hildenbrand a écrit :
>>>                    |            |                  |         |> +
>>> ffffffc000000000 | -256    GB | ffffffc7ffffffff |   32 GB | kasan
>>>> +   ffffffcefee00000 | -196    GB | ffffffcefeffffff |    2 MB | fixmap
>>>> +   ffffffceff000000 | -196    GB | ffffffceffffffff |   16 MB | PCI io
>>>> +   ffffffcf00000000 | -196    GB | ffffffcfffffffff |    4 GB | vmemmap
>>>> +   ffffffd000000000 | -192    GB | ffffffdfffffffff |   64 GB |
>>>> vmalloc/ioremap space
>>>> +   ffffffe000000000 | -128    GB | ffffffff7fffffff |  126 GB |
>>>> direct mapping of all physical memory
>>>
>>> ^ So you could never ever have more than 126 GB, correct?
>>>
>>> I assume that's nothing new.
>>>
>>
>> Before this patch, the limit was 128GB, so in my sense, there is nothing
>> new. If ever we want to increase that limit, we'll just have to lower
>> PAGE_OFFSET, there is still some unused virtual addresses after kasan
>> for example.
> 
> Linus Walleij is looking into changing the arm32 code to have the kernel
> direct map inside of the vmalloc area, which would be another place
> that you could use here. It would be nice to not have too many different
> ways of doing this, but I'm not sure how hard it would be to rework your
> code, or if there are any downsides of doing this.

This was what my previous version did: https://lkml.org/lkml/2020/6/7/28.

This approach was not welcomed very well and it fixed only the problem 
of the implementation of relocatable kernel. The second issue I'm trying 
to resolve here is to support both 3 and 4 level page tables using the 
same kernel without being relocatable (which would introduce performance 
penalty). I can't do it when the kernel mapping is in the vmalloc region 
since vmalloc region relies on PAGE_OFFSET which is different on both 3 
and 4 level page table and that would then require the kernel to be 
relocatable.

Alex

> 
>          Arnd
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
> 


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 2/3] Documentation: riscv: Add documentation that describes the VM layout
  2021-03-10 19:12         ` Alex Ghiti
@ 2021-03-11  8:42           ` Arnd Bergmann
  2021-03-13  8:23             ` Alex Ghiti
  0 siblings, 1 reply; 15+ messages in thread
From: Arnd Bergmann @ 2021-03-11  8:42 UTC (permalink / raw)
  To: Alexandre Ghiti
  Cc: David Hildenbrand, Jonathan Corbet, Paul Walmsley,
	Palmer Dabbelt, Albert Ou, Andrey Ryabinin, Alexander Potapenko,
	Dmitry Vyukov, open list:DOCUMENTATION, linux-riscv,
	linux-kernel, kasan-dev, linux-arch, Linux-MM, Linus Walleij

On Wed, Mar 10, 2021 at 8:12 PM Alex Ghiti <alex@ghiti.fr> wrote:
> Le 3/10/21 à 6:42 AM, Arnd Bergmann a écrit :
> > On Thu, Feb 25, 2021 at 12:56 PM Alex Ghiti <alex@ghiti.fr> wrote:
> >>
> >> Le 2/25/21 à 5:34 AM, David Hildenbrand a écrit :
> >>>                    |            |                  |         |> +
> >>> ffffffc000000000 | -256    GB | ffffffc7ffffffff |   32 GB | kasan
> >>>> +   ffffffcefee00000 | -196    GB | ffffffcefeffffff |    2 MB | fixmap
> >>>> +   ffffffceff000000 | -196    GB | ffffffceffffffff |   16 MB | PCI io
> >>>> +   ffffffcf00000000 | -196    GB | ffffffcfffffffff |    4 GB | vmemmap
> >>>> +   ffffffd000000000 | -192    GB | ffffffdfffffffff |   64 GB |
> >>>> vmalloc/ioremap space
> >>>> +   ffffffe000000000 | -128    GB | ffffffff7fffffff |  126 GB |
> >>>> direct mapping of all physical memory
> >>>
> >>> ^ So you could never ever have more than 126 GB, correct?
> >>>
> >>> I assume that's nothing new.
> >>>
> >>
> >> Before this patch, the limit was 128GB, so in my sense, there is nothing
> >> new. If ever we want to increase that limit, we'll just have to lower
> >> PAGE_OFFSET, there is still some unused virtual addresses after kasan
> >> for example.
> >
> > Linus Walleij is looking into changing the arm32 code to have the kernel
> > direct map inside of the vmalloc area, which would be another place
> > that you could use here. It would be nice to not have too many different
> > ways of doing this, but I'm not sure how hard it would be to rework your
> > code, or if there are any downsides of doing this.
>
> This was what my previous version did: https://lkml.org/lkml/2020/6/7/28.
>
> This approach was not welcomed very well and it fixed only the problem
> of the implementation of relocatable kernel. The second issue I'm trying
> to resolve here is to support both 3 and 4 level page tables using the
> same kernel without being relocatable (which would introduce performance
> penalty). I can't do it when the kernel mapping is in the vmalloc region
> since vmalloc region relies on PAGE_OFFSET which is different on both 3
> and 4 level page table and that would then require the kernel to be
> relocatable.

Ok, I see.

I suppose it might work if you moved the direct-map to the lowest
address and the vmalloc area (incorporating the kernel mapping,
modules, pio, and fixmap at fixed addresses) to the very top of the
address space, but you probably already considered and rejected
that for other reasons.

         Arnd


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 2/3] Documentation: riscv: Add documentation that describes the VM layout
  2021-03-11  8:42           ` Arnd Bergmann
@ 2021-03-13  8:23             ` Alex Ghiti
  2021-03-13 22:34               ` Arnd Bergmann
  0 siblings, 1 reply; 15+ messages in thread
From: Alex Ghiti @ 2021-03-13  8:23 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: David Hildenbrand, Jonathan Corbet, Paul Walmsley,
	Palmer Dabbelt, Albert Ou, Andrey Ryabinin, Alexander Potapenko,
	Dmitry Vyukov, open list:DOCUMENTATION, linux-riscv,
	linux-kernel, kasan-dev, linux-arch, Linux-MM, Linus Walleij

Hi Arnd,

Le 3/11/21 à 3:42 AM, Arnd Bergmann a écrit :
> On Wed, Mar 10, 2021 at 8:12 PM Alex Ghiti <alex@ghiti.fr> wrote:
>> Le 3/10/21 à 6:42 AM, Arnd Bergmann a écrit :
>>> On Thu, Feb 25, 2021 at 12:56 PM Alex Ghiti <alex@ghiti.fr> wrote:
>>>>
>>>> Le 2/25/21 à 5:34 AM, David Hildenbrand a écrit :
>>>>>                     |            |                  |         |> +
>>>>> ffffffc000000000 | -256    GB | ffffffc7ffffffff |   32 GB | kasan
>>>>>> +   ffffffcefee00000 | -196    GB | ffffffcefeffffff |    2 MB | fixmap
>>>>>> +   ffffffceff000000 | -196    GB | ffffffceffffffff |   16 MB | PCI io
>>>>>> +   ffffffcf00000000 | -196    GB | ffffffcfffffffff |    4 GB | vmemmap
>>>>>> +   ffffffd000000000 | -192    GB | ffffffdfffffffff |   64 GB |
>>>>>> vmalloc/ioremap space
>>>>>> +   ffffffe000000000 | -128    GB | ffffffff7fffffff |  126 GB |
>>>>>> direct mapping of all physical memory
>>>>>
>>>>> ^ So you could never ever have more than 126 GB, correct?
>>>>>
>>>>> I assume that's nothing new.
>>>>>
>>>>
>>>> Before this patch, the limit was 128GB, so in my sense, there is nothing
>>>> new. If ever we want to increase that limit, we'll just have to lower
>>>> PAGE_OFFSET, there is still some unused virtual addresses after kasan
>>>> for example.
>>>
>>> Linus Walleij is looking into changing the arm32 code to have the kernel
>>> direct map inside of the vmalloc area, which would be another place
>>> that you could use here. It would be nice to not have too many different
>>> ways of doing this, but I'm not sure how hard it would be to rework your
>>> code, or if there are any downsides of doing this.
>>
>> This was what my previous version did: https://lkml.org/lkml/2020/6/7/28.
>>
>> This approach was not welcomed very well and it fixed only the problem
>> of the implementation of relocatable kernel. The second issue I'm trying
>> to resolve here is to support both 3 and 4 level page tables using the
>> same kernel without being relocatable (which would introduce performance
>> penalty). I can't do it when the kernel mapping is in the vmalloc region
>> since vmalloc region relies on PAGE_OFFSET which is different on both 3
>> and 4 level page table and that would then require the kernel to be
>> relocatable.
> 
> Ok, I see.
> 
> I suppose it might work if you moved the direct-map to the lowest
> address and the vmalloc area (incorporating the kernel mapping,
> modules, pio, and fixmap at fixed addresses) to the very top of the
> address space, but you probably already considered and rejected
> that for other reasons.
> 

Yes I considered it...when you re-proposed it :) I'm not opposed to your 
solution in the vmalloc region but I can't find any advantage over the 
current solution, are there ? That would harmonize with Linus's work, 
but then we'd be quite different from x86 address space.

And by the way, thanks for having suggested the current solution in a 
previous conversation :)

Thanks again,

Alex

>           Arnd
> 


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/3] Move kernel mapping outside the linear mapping
  2021-03-10  2:54 ` [PATCH 0/3] Move kernel mapping outside the linear mapping Palmer Dabbelt
@ 2021-03-13  9:26   ` Alex Ghiti
  2021-03-17  5:05     ` Palmer Dabbelt
  2021-03-20  8:48   ` Alex Ghiti
  1 sibling, 1 reply; 15+ messages in thread
From: Alex Ghiti @ 2021-03-13  9:26 UTC (permalink / raw)
  To: Palmer Dabbelt
  Cc: corbet, Paul Walmsley, aou, Arnd Bergmann, aryabinin, glider,
	dvyukov, linux-doc, linux-riscv, linux-kernel, kasan-dev,
	linux-arch, linux-mm

Hi Palmer,

Le 3/9/21 à 9:54 PM, Palmer Dabbelt a écrit :
> On Thu, 25 Feb 2021 00:04:50 PST (-0800), alex@ghiti.fr wrote:
>> I decided to split sv48 support in small series to ease the review.
>>
>> This patchset pushes the kernel mapping (modules and BPF too) to the last
>> 4GB of the 64bit address space, this allows to:
>> - implement relocatable kernel (that will come later in another
>>   patchset) that requires to move the kernel mapping out of the linear
>>   mapping to avoid to copy the kernel at a different physical address.
>> - have a single kernel that is not relocatable (and then that avoids the
>>   performance penalty imposed by PIC kernel) for both sv39 and sv48.
>>
>> The first patch implements this behaviour, the second patch introduces a
>> documentation that describes the virtual address space layout of the 
>> 64bit
>> kernel and the last patch is taken from my sv48 series where I simply 
>> added
>> the dump of the modules/kernel/BPF mapping.
>>
>> I removed the Reviewed-by on the first patch since it changed enough from
>> last time and deserves a second look.
>>
>> Alexandre Ghiti (3):
>>   riscv: Move kernel mapping outside of linear mapping
>>   Documentation: riscv: Add documentation that describes the VM layout
>>   riscv: Prepare ptdump for vm layout dynamic addresses
>>
>>  Documentation/riscv/index.rst       |  1 +
>>  Documentation/riscv/vm-layout.rst   | 61 ++++++++++++++++++++++
>>  arch/riscv/boot/loader.lds.S        |  3 +-
>>  arch/riscv/include/asm/page.h       | 18 ++++++-
>>  arch/riscv/include/asm/pgtable.h    | 37 +++++++++----
>>  arch/riscv/include/asm/set_memory.h |  1 +
>>  arch/riscv/kernel/head.S            |  3 +-
>>  arch/riscv/kernel/module.c          |  6 +--
>>  arch/riscv/kernel/setup.c           |  3 ++
>>  arch/riscv/kernel/vmlinux.lds.S     |  3 +-
>>  arch/riscv/mm/fault.c               | 13 +++++
>>  arch/riscv/mm/init.c                | 81 +++++++++++++++++++++++------
>>  arch/riscv/mm/kasan_init.c          |  9 ++++
>>  arch/riscv/mm/physaddr.c            |  2 +-
>>  arch/riscv/mm/ptdump.c              | 67 +++++++++++++++++++-----
>>  15 files changed, 258 insertions(+), 50 deletions(-)
>>  create mode 100644 Documentation/riscv/vm-layout.rst
> 
> This generally looks good, but I'm getting a bunch of checkpatch 
> warnings and some conflicts, do you mind fixing those up (and including 
> your other kasan patch, as that's likely to conflict)?


I fixed a few checkpatch warnings and rebased on top of for-next but had 
not conflicts.

I have just sent the v2.

Thanks,

Alex



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 2/3] Documentation: riscv: Add documentation that describes the VM layout
  2021-03-13  8:23             ` Alex Ghiti
@ 2021-03-13 22:34               ` Arnd Bergmann
  0 siblings, 0 replies; 15+ messages in thread
From: Arnd Bergmann @ 2021-03-13 22:34 UTC (permalink / raw)
  To: Alexandre Ghiti
  Cc: David Hildenbrand, Jonathan Corbet, Paul Walmsley,
	Palmer Dabbelt, Albert Ou, Andrey Ryabinin, Alexander Potapenko,
	Dmitry Vyukov, open list:DOCUMENTATION, linux-riscv,
	linux-kernel, kasan-dev, linux-arch, Linux-MM, Linus Walleij

On Sat, Mar 13, 2021 at 9:23 AM Alex Ghiti <alex@ghiti.fr> wrote:
>
> Yes I considered it...when you re-proposed it :) I'm not opposed to your
> solution in the vmalloc region but I can't find any advantage over the
> current solution, are there ? That would harmonize with Linus's work,
> but then we'd be quite different from x86 address space.
>
> And by the way, thanks for having suggested the current solution in a
> previous conversation :)

Ah, I really need to keep track better of what I already commented on...

      Arnd


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/3] Move kernel mapping outside the linear mapping
  2021-03-13  9:26   ` Alex Ghiti
@ 2021-03-17  5:05     ` Palmer Dabbelt
  0 siblings, 0 replies; 15+ messages in thread
From: Palmer Dabbelt @ 2021-03-17  5:05 UTC (permalink / raw)
  To: alex
  Cc: corbet, Paul Walmsley, aou, Arnd Bergmann, aryabinin, glider,
	dvyukov, linux-doc, linux-riscv, linux-kernel, kasan-dev,
	linux-arch, linux-mm

On Sat, 13 Mar 2021 01:26:47 PST (-0800), alex@ghiti.fr wrote:
> Hi Palmer,
>
> Le 3/9/21 à 9:54 PM, Palmer Dabbelt a écrit :
>> On Thu, 25 Feb 2021 00:04:50 PST (-0800), alex@ghiti.fr wrote:
>>> I decided to split sv48 support in small series to ease the review.
>>>
>>> This patchset pushes the kernel mapping (modules and BPF too) to the last
>>> 4GB of the 64bit address space, this allows to:
>>> - implement relocatable kernel (that will come later in another
>>>   patchset) that requires to move the kernel mapping out of the linear
>>>   mapping to avoid to copy the kernel at a different physical address.
>>> - have a single kernel that is not relocatable (and then that avoids the
>>>   performance penalty imposed by PIC kernel) for both sv39 and sv48.
>>>
>>> The first patch implements this behaviour, the second patch introduces a
>>> documentation that describes the virtual address space layout of the
>>> 64bit
>>> kernel and the last patch is taken from my sv48 series where I simply
>>> added
>>> the dump of the modules/kernel/BPF mapping.
>>>
>>> I removed the Reviewed-by on the first patch since it changed enough from
>>> last time and deserves a second look.
>>>
>>> Alexandre Ghiti (3):
>>>   riscv: Move kernel mapping outside of linear mapping
>>>   Documentation: riscv: Add documentation that describes the VM layout
>>>   riscv: Prepare ptdump for vm layout dynamic addresses
>>>
>>>  Documentation/riscv/index.rst       |  1 +
>>>  Documentation/riscv/vm-layout.rst   | 61 ++++++++++++++++++++++
>>>  arch/riscv/boot/loader.lds.S        |  3 +-
>>>  arch/riscv/include/asm/page.h       | 18 ++++++-
>>>  arch/riscv/include/asm/pgtable.h    | 37 +++++++++----
>>>  arch/riscv/include/asm/set_memory.h |  1 +
>>>  arch/riscv/kernel/head.S            |  3 +-
>>>  arch/riscv/kernel/module.c          |  6 +--
>>>  arch/riscv/kernel/setup.c           |  3 ++
>>>  arch/riscv/kernel/vmlinux.lds.S     |  3 +-
>>>  arch/riscv/mm/fault.c               | 13 +++++
>>>  arch/riscv/mm/init.c                | 81 +++++++++++++++++++++++------
>>>  arch/riscv/mm/kasan_init.c          |  9 ++++
>>>  arch/riscv/mm/physaddr.c            |  2 +-
>>>  arch/riscv/mm/ptdump.c              | 67 +++++++++++++++++++-----
>>>  15 files changed, 258 insertions(+), 50 deletions(-)
>>>  create mode 100644 Documentation/riscv/vm-layout.rst
>>
>> This generally looks good, but I'm getting a bunch of checkpatch
>> warnings and some conflicts, do you mind fixing those up (and including
>> your other kasan patch, as that's likely to conflict)?
>
>
> I fixed a few checkpatch warnings and rebased on top of for-next but had
> not conflicts.
>
> I have just sent the v2.

Thanks.  These (and the second patch of the one I just put on fixes) are
for-next things, so I'm not going to get a look at them tonight because I want
to make sure we don't have any more fixes outstanding.


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/3] Move kernel mapping outside the linear mapping
  2021-03-10  2:54 ` [PATCH 0/3] Move kernel mapping outside the linear mapping Palmer Dabbelt
  2021-03-13  9:26   ` Alex Ghiti
@ 2021-03-20  8:48   ` Alex Ghiti
  1 sibling, 0 replies; 15+ messages in thread
From: Alex Ghiti @ 2021-03-20  8:48 UTC (permalink / raw)
  To: Palmer Dabbelt
  Cc: corbet, Paul Walmsley, aou, Arnd Bergmann, aryabinin, glider,
	dvyukov, linux-doc, linux-riscv, linux-kernel, kasan-dev,
	linux-arch, linux-mm

Le 3/9/21 à 9:54 PM, Palmer Dabbelt a écrit :
> On Thu, 25 Feb 2021 00:04:50 PST (-0800), alex@ghiti.fr wrote:
>> I decided to split sv48 support in small series to ease the review.
>>
>> This patchset pushes the kernel mapping (modules and BPF too) to the last
>> 4GB of the 64bit address space, this allows to:
>> - implement relocatable kernel (that will come later in another
>>   patchset) that requires to move the kernel mapping out of the linear
>>   mapping to avoid to copy the kernel at a different physical address.
>> - have a single kernel that is not relocatable (and then that avoids the
>>   performance penalty imposed by PIC kernel) for both sv39 and sv48.
>>
>> The first patch implements this behaviour, the second patch introduces a
>> documentation that describes the virtual address space layout of the 
>> 64bit
>> kernel and the last patch is taken from my sv48 series where I simply 
>> added
>> the dump of the modules/kernel/BPF mapping.
>>
>> I removed the Reviewed-by on the first patch since it changed enough from
>> last time and deserves a second look.
>>
>> Alexandre Ghiti (3):
>>   riscv: Move kernel mapping outside of linear mapping
>>   Documentation: riscv: Add documentation that describes the VM layout
>>   riscv: Prepare ptdump for vm layout dynamic addresses
>>
>>  Documentation/riscv/index.rst       |  1 +
>>  Documentation/riscv/vm-layout.rst   | 61 ++++++++++++++++++++++
>>  arch/riscv/boot/loader.lds.S        |  3 +-
>>  arch/riscv/include/asm/page.h       | 18 ++++++-
>>  arch/riscv/include/asm/pgtable.h    | 37 +++++++++----
>>  arch/riscv/include/asm/set_memory.h |  1 +
>>  arch/riscv/kernel/head.S            |  3 +-
>>  arch/riscv/kernel/module.c          |  6 +--
>>  arch/riscv/kernel/setup.c           |  3 ++
>>  arch/riscv/kernel/vmlinux.lds.S     |  3 +-
>>  arch/riscv/mm/fault.c               | 13 +++++
>>  arch/riscv/mm/init.c                | 81 +++++++++++++++++++++++------
>>  arch/riscv/mm/kasan_init.c          |  9 ++++
>>  arch/riscv/mm/physaddr.c            |  2 +-
>>  arch/riscv/mm/ptdump.c              | 67 +++++++++++++++++++-----
>>  15 files changed, 258 insertions(+), 50 deletions(-)
>>  create mode 100644 Documentation/riscv/vm-layout.rst
> 
> This generally looks good, but I'm getting a bunch of checkpatch 
> warnings and some conflicts, do you mind fixing those up (and including 
> your other kasan patch, as that's likely to conflict)?

I have just tried to rebase this on for-next, and that quite conflicts 
with Vitaly's XIP patch, I'm fixing this and post a v3.

Alex


^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2021-03-20  8:48 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-25  8:04 [PATCH 0/3] Move kernel mapping outside the linear mapping Alexandre Ghiti
2021-02-25  8:04 ` [PATCH 1/3] riscv: Move kernel mapping outside of " Alexandre Ghiti
2021-02-25  8:04 ` [PATCH 2/3] Documentation: riscv: Add documentation that describes the VM layout Alexandre Ghiti
2021-02-25 10:34   ` David Hildenbrand
2021-02-25 11:56     ` Alex Ghiti
2021-03-10 11:42       ` Arnd Bergmann
2021-03-10 19:12         ` Alex Ghiti
2021-03-11  8:42           ` Arnd Bergmann
2021-03-13  8:23             ` Alex Ghiti
2021-03-13 22:34               ` Arnd Bergmann
2021-02-25  8:04 ` [PATCH 3/3] riscv: Prepare ptdump for vm layout dynamic addresses Alexandre Ghiti
2021-03-10  2:54 ` [PATCH 0/3] Move kernel mapping outside the linear mapping Palmer Dabbelt
2021-03-13  9:26   ` Alex Ghiti
2021-03-17  5:05     ` Palmer Dabbelt
2021-03-20  8:48   ` Alex Ghiti

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).