[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f38979dc-9f8c-6fce-6b1b-70e5f110e14c@ghiti.fr>
Date: Sat, 30 Jan 2021 04:33:20 -0500
From: Alex Ghiti <alex@...ti.fr>
To: Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Zong Li <zong.li@...ive.com>, Anup Patel <anup@...infault.org>,
Christoph Hellwig <hch@....de>,
Ard Biesheuvel <ardb@...nel.org>,
Arnd Bergmann <arnd@...db.de>, linux-efi@...r.kernel.org,
linux-arch@...r.kernel.org, linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 00/12] Introduce sv48 support without relocable kernel
Hi Palmer,
On 1/4/21 2:58 PM, Alexandre Ghiti wrote:
> This patchset, contrary to the previous versions, allows to have a single
> kernel for sv39 and sv48 without being relocatable.
>
> The idea comes from Arnd Bergmann who suggested to do the same as x86,
> that is mapping the kernel to the end of the address space, which allows
> the kernel to be linked at the same address for both sv39 and sv48 and
> then does not require to be relocated at runtime.
>
> This is an RFC because I need to at least rebase a few commits and add
> documentation. The most interesting patches where I expect feedbacks are
> 1/12, 2/12 and 8/12. Note that moving the kernel out of the linear
> mapping and sv48 support can be separate patchsets, I share them together
> today to show that it works (this patchset is rebased on top of v5.10).
>
> If we agree about the overall idea, I'll rebase my relocatable patchset
> on top of that and then KASLR implementation from Zong will be greatly
> simplified since moving the kernel out of the linear mapping will avoid
> to copy the kernel physically.
>
> This implements sv48 support at runtime. The kernel will try to
> boot with 4-level page table and will fallback to 3-level if the HW does not
> support it. Folding the 4th level into a 3-level page table has almost no
> cost at runtime.
>
> Finally, the user can now ask for sv39 explicitly by using the device-tree
> which will reduce memory footprint and reduce the number of memory accesses
> in case of TLB miss.
>
> Alexandre Ghiti (12):
> riscv: Move kernel mapping outside of linear mapping
> riscv: Protect the kernel linear mapping
> riscv: Get rid of compile time logic with MAX_EARLY_MAPPING_SIZE
> riscv: Allow to dynamically define VA_BITS
> riscv: Simplify MAXPHYSMEM config
> riscv: Prepare ptdump for vm layout dynamic addresses
> asm-generic: Prepare for riscv use of pud_alloc_one and pud_free
> riscv: Implement sv48 support
> riscv: Allow user to downgrade to sv39 when hw supports sv48
> riscv: Use pgtable_l4_enabled to output mmu type in cpuinfo
> riscv: Explicit comment about user virtual address space size
> riscv: Improve virtual kernel memory layout dump
>
> arch/riscv/Kconfig | 34 +--
> arch/riscv/boot/loader.lds.S | 3 +-
> arch/riscv/include/asm/csr.h | 3 +-
> arch/riscv/include/asm/fixmap.h | 3 +
> arch/riscv/include/asm/page.h | 33 ++-
> arch/riscv/include/asm/pgalloc.h | 40 +++
> arch/riscv/include/asm/pgtable-64.h | 104 ++++++-
> arch/riscv/include/asm/pgtable.h | 68 +++--
> arch/riscv/include/asm/sparsemem.h | 6 +-
> arch/riscv/kernel/cpu.c | 23 +-
> arch/riscv/kernel/head.S | 6 +-
> arch/riscv/kernel/module.c | 4 +-
> arch/riscv/kernel/vmlinux.lds.S | 3 +-
> arch/riscv/mm/context.c | 2 +-
> arch/riscv/mm/init.c | 376 ++++++++++++++++++++----
> arch/riscv/mm/physaddr.c | 2 +-
> arch/riscv/mm/ptdump.c | 56 +++-
> drivers/firmware/efi/libstub/efi-stub.c | 2 +-
> include/asm-generic/pgalloc.h | 24 +-
> include/linux/sizes.h | 3 +-
> 20 files changed, 648 insertions(+), 147 deletions(-)
>
Any thought about the idea ? Is it going in the right direction ? I have
fixed quite a few things since I posted this so don't bother giving this
patchset a full review.
Thanks,
Alex
Powered by blists - more mailing lists