From: Alex Ghiti <alex@ghiti.fr>
To: Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>, Zong Li <zong.li@sifive.com>,
Anup Patel <anup@brainfault.org>, Christoph Hellwig <hch@lst.de>,
Ard Biesheuvel <ardb@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
linux-efi@vger.kernel.org, linux-arch@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 00/12] Introduce sv48 support without relocable kernel
Date: Sat, 30 Jan 2021 04:33:20 -0500 [thread overview]
Message-ID: <f38979dc-9f8c-6fce-6b1b-70e5f110e14c@ghiti.fr> (raw)
In-Reply-To: <20210104195840.1593-1-alex@ghiti.fr>
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
next prev parent reply other threads:[~2021-01-30 9:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-04 19:58 [RFC PATCH 00/12] Introduce sv48 support without relocable kernel Alexandre Ghiti
2021-01-04 19:58 ` [RFC PATCH 01/12] riscv: Move kernel mapping outside of linear mapping Alexandre Ghiti
2021-01-05 11:40 ` Anup Patel
2021-01-06 6:36 ` Alex Ghiti
2021-01-06 6:44 ` Anup Patel
2021-01-06 8:16 ` Alex Ghiti
2021-01-04 19:58 ` [RFC PATCH 02/12] riscv: Protect the kernel " Alexandre Ghiti
2021-01-05 11:50 ` Anup Patel
2021-01-04 19:58 ` [RFC PATCH 03/12] riscv: Get rid of compile time logic with MAX_EARLY_MAPPING_SIZE Alexandre Ghiti
2021-01-04 19:58 ` [RFC PATCH 04/12] riscv: Allow to dynamically define VA_BITS Alexandre Ghiti
2021-01-05 12:06 ` Anup Patel
2021-01-06 6:38 ` Alex Ghiti
2021-01-04 19:58 ` [RFC PATCH 05/12] riscv: Simplify MAXPHYSMEM config Alexandre Ghiti
2021-01-04 19:58 ` [RFC PATCH 06/12] riscv: Prepare ptdump for vm layout dynamic addresses Alexandre Ghiti
2021-01-04 19:58 ` [RFC PATCH 07/12] asm-generic: Prepare for riscv use of pud_alloc_one and pud_free Alexandre Ghiti
2021-01-04 19:58 ` [RFC PATCH 08/12] riscv: Implement sv48 support Alexandre Ghiti
2021-01-04 19:58 ` [RFC PATCH 09/12] riscv: Allow user to downgrade to sv39 when hw supports sv48 Alexandre Ghiti
2021-01-04 19:58 ` [RFC PATCH 10/12] riscv: Use pgtable_l4_enabled to output mmu type in cpuinfo Alexandre Ghiti
2021-01-04 19:58 ` [RFC PATCH 11/12] riscv: Explicit comment about user virtual address space size Alexandre Ghiti
2021-01-04 19:58 ` [RFC PATCH 12/12] riscv: Improve virtual kernel memory layout dump Alexandre Ghiti
2021-01-30 9:33 ` Alex Ghiti [this message]
2021-02-03 3:04 ` [RFC PATCH 00/12] Introduce sv48 support without relocable kernel Palmer Dabbelt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f38979dc-9f8c-6fce-6b1b-70e5f110e14c@ghiti.fr \
--to=alex@ghiti.fr \
--cc=anup@brainfault.org \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=hch@lst.de \
--cc=linux-arch@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=zong.li@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).