Re: [PATCH v2 3/5] RISC-V: Allow booting kernel from any 4KB aligned address

[Anup Patel]

On Sat, Mar 23, 2019 at 9:10 PM Mike Rapoport <rppt@xxxxxxxxxxxxx> wrote:
>
> On Thu, Mar 21, 2019 at 09:47:51AM +0000, Anup Patel wrote:
> > Currently, we have to boot RISCV64 kernel from a 2MB aligned physical
> > address and RISCV32 kernel from a 4MB aligned physical address. This
> > constraint is because initial pagetable setup (i.e. setup_vm()) maps
> > entire RAM using hugepages (i.e. 2MB for 3-level pagetable and 4MB for
> > 2-level pagetable).
> >
> > Further, the above booting contraint also results in memory wastage
> > because if we boot kernel from some <xyz> address (which is not same as
> > RAM start address) then RISCV kernel will map PAGE_OFFSET virtual address
> > lineraly to <xyz> physical address and memory between RAM start and <xyz>
> > will be reserved/unusable.
> >
> > For example, RISCV64 kernel booted from 0x80200000 will waste 2MB of RAM
> > and RISCV32 kernel booted from 0x80400000 will waste 4MB of RAM.
> >
> > This patch re-writes the initial pagetable setup code to allow booting
> > RISV32 and RISCV64 kernel from any 4KB (i.e. PAGE_SIZE) aligned address.
> >
> > To achieve this:
> > 1. We add kconfig option BOOT_PAGE_ALIGNED. When it is enabled we use
> >    4KB mappings in initial page table setup otherwise we use 2MB/4MB
> >    mappings.
> > 2. We map kernel and dtb (few MBs) in setup_vm() (called from head.S)
> > 3. Once we reach paging_init() (called from setup_arch()) after
> >    memblock setup, we map all available memory banks.
> >
> > With this patch in-place, the booting constraint for RISCV32 and RISCV64
> > kernel is much more relaxed when CONFIG_BOOT_PAGE_ALIGNED=y and we can
> > now boot kernel very close to RAM start thereby minimizng memory wastage.
>
> I have no general objection, but I presume the patch will be significantly
> simplified if the addition of 4K pages support will follow the removal of
> the trampoline_pd_dir.
>
> That said, I didn't look into the details, since they will change
> substantially, only some comments on the Kconfig part.
>
> On the high level, have you considered using large pages in setup_vm() and
> the remapping everything with 4K pages in setup_vm_final()?  This might
> save you the whole ops-> churn.

Yes, it can save the ops churn in setup_vm() but we should let setup_vm()
choose best possible mapping size based on load address alignment hence
it's better have common page table setup code shared between early and
final page table setup which can create mapping of any size.

For example, if we are booted from 1G aligned load address then setup_vm()
should create 1G mapping thereby getting better performance compared to
2M mappings.

Regards,
Anup