Re: [RFC PATCH 1/7] riscv: Get rid of compile time logic with MAX_EARLY_MAPPING_SIZE

From: Palmer Dabbelt
Date: Fri Apr 03 2020 - 11:17:12 EST


On Sun, 22 Mar 2020 04:00:22 PDT (-0700), alex@xxxxxxxx wrote:
There is no need to compare at compile time MAX_EARLY_MAPPING_SIZE value
with PGDIR_SIZE since MAX_EARLY_MAPPING_SIZE is set to 128MB which is less
than PGDIR_SIZE that is equal to 1GB: that allows to simplify early_pmd
definition.

Signed-off-by: Alexandre Ghiti <alex@xxxxxxxx>
---
arch/riscv/mm/init.c | 16 ++++------------
1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 238bd0033c3f..18bbb426848e 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -247,13 +247,7 @@ static void __init create_pte_mapping(pte_t *ptep,

pmd_t trampoline_pmd[PTRS_PER_PMD] __page_aligned_bss;
pmd_t fixmap_pmd[PTRS_PER_PMD] __page_aligned_bss;
-
-#if MAX_EARLY_MAPPING_SIZE < PGDIR_SIZE
-#define NUM_EARLY_PMDS 1UL
-#else
-#define NUM_EARLY_PMDS (1UL + MAX_EARLY_MAPPING_SIZE / PGDIR_SIZE)
-#endif
-pmd_t early_pmd[PTRS_PER_PMD * NUM_EARLY_PMDS] __initdata __aligned(PAGE_SIZE);
+pmd_t early_pmd[PTRS_PER_PMD] __initdata __aligned(PAGE_SIZE);

static pmd_t *__init get_pmd_virt(phys_addr_t pa)
{
@@ -267,14 +261,12 @@ static pmd_t *__init get_pmd_virt(phys_addr_t pa)

static phys_addr_t __init alloc_pmd(uintptr_t va)
{
- uintptr_t pmd_num;
-
if (mmu_enabled)
return memblock_phys_alloc(PAGE_SIZE, PAGE_SIZE);

- pmd_num = (va - PAGE_OFFSET) >> PGDIR_SHIFT;
- BUG_ON(pmd_num >= NUM_EARLY_PMDS);
- return (uintptr_t)&early_pmd[pmd_num * PTRS_PER_PMD];
+ BUG_ON((va - PAGE_OFFSET) >> PGDIR_SHIFT);
+
+ return (uintptr_t)early_pmd;
}

static void __init create_pmd_mapping(pmd_t *pmdp,

My specific worry here was that allyesconfig kernels are quite large, and that
dropping the code to handle large kernels would make it even harder to boot
them. That said, I can't actually get one to boot so I'm happy to just push
that off until later and drop the code we can't practically use.

Reviewed-by: Palmer Dabbelt <palmerdabbelt@xxxxxxxxxx>

Thanks!