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

[Alex Ghiti]

On 4/3/20 11:17 AM, Palmer Dabbelt wrote:
> 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!

Thanks,

Alex