Re: [PATCH] riscv: Start of DRAM should at least be aligned on PMD size for the direct mapping

From: Alexandre Ghiti
Date: Tue Jul 04 2023 - 09:18:05 EST


On Tue, Jul 4, 2023 at 2:26 PM Conor Dooley <conor.dooley@xxxxxxxxxxxxx> wrote:
>
> Hey Alex,
>
> On Tue, Jul 04, 2023 at 02:18:37PM +0200, Alexandre Ghiti wrote:
> > So that we do not end up mapping the whole linear mapping using 4K
> > pages, which is slow at boot time, and also very likely at runtime.
> >
> > So make sure we align the start of DRAM on a PMD boundary.
> >
> > Signed-off-by: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
>
> Obviously correct me if I am wrong here, but was this not reported by
> Song Shuai as a regression?
> Accordingly, should this not have Reported-by, Closes/Link & Fixes tags?

Sure we should add the reported by from Song as he did the proper report :)

Reported-by: Song Shuai <suagrfillet@xxxxxxxxx>
Closes: https://lore.kernel.org/linux-riscv/20230625140931.1266216-1-songshuaishuai@xxxxxxxxxxx/

And yes sorry, I thought it was there before, but it was actually when
I retrieved the first 2MB that the problem appeared, so:

Fixes: 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping")

Thanks!

>
> Cheers,
> Conor.
>
> > ---
> > arch/riscv/mm/init.c | 7 ++++++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> > index 4fa420faa780..4a43ec275c6d 100644
> > --- a/arch/riscv/mm/init.c
> > +++ b/arch/riscv/mm/init.c
> > @@ -214,8 +214,13 @@ static void __init setup_bootmem(void)
> > memblock_reserve(vmlinux_start, vmlinux_end - vmlinux_start);
> >
> > phys_ram_end = memblock_end_of_DRAM();
> > +
> > + /*
> > + * Make sure we align the start of the memory on a PMD boundary so that
> > + * at worst, we map the linear mapping with PMD mappings.
> > + */
> > if (!IS_ENABLED(CONFIG_XIP_KERNEL))
> > - phys_ram_base = memblock_start_of_DRAM();
> > + phys_ram_base = memblock_start_of_DRAM() & PMD_MASK;
> >
> > /*
> > * In 64-bit, any use of __va/__pa before this point is wrong as we
> > --
> > 2.39.2
> >