| Message ID | alpine.DEB.2.21.9999.1907261259420.26670@viisi.sifive.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | riscv: kbuild: add virtual memory system selection | expand |
On Sat, Jul 27, 2019 at 4:00 AM Paul Walmsley <paul.walmsley@sifive.com> wrote: > > > The RISC-V specifications currently define three virtual memory > translation systems: Sv32, Sv39, and Sv48. Sv32 is currently specific > to 32-bit systems; Sv39 and Sv48 are currently specific to 64-bit > systems. The current kernel only supports Sv32 and Sv39, but we'd > like to start preparing for Sv48. As an initial step, allow the > virtual memory translation system to be selected via kbuild, and stop > the build if an option is selected that the kernel doen't currently > support. > > This patch currently has no functional impact. > > Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com> > Cc: Alexandre Ghiti <alex@ghiti.fr> > --- > arch/riscv/Kconfig | 43 +++++++++++++++++++++++++++++ > arch/riscv/include/asm/pgtable-32.h | 4 +++ > arch/riscv/include/asm/pgtable-64.h | 4 +++ > 3 files changed, 51 insertions(+) > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index 59a4727ecd6c..8ef64fe2c2b3 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -155,6 +155,49 @@ config MODULE_SECTIONS > bool > select HAVE_MOD_ARCH_SPECIFIC > > +choice > + prompt "Virtual Memory System" > + default RISCV_VM_SV32 if 32BIT > + default RISCV_VM_SV39 if 64BIT > + help > + The RISC-V Instruction Set Manual Volume II: Privileged > + Architecture defines several different "virtual memory > + systems" which specify virtual and physical address formats > + and the structure of page table entries. This determines > + the amount of virtual address space present and how it is > + translated into physical addresses. > + > + config RISCV_VM_SV32 > + depends on 32BIT > + bool "RISC-V Sv32" > + help > + The Sv32 virtual memory system is a page-based > + address and page table format for RV32 systems. > + It specifies a translation between 32-bit virtual > + addresses and 33-bit physical addresses, via a > + two-stage page table layout. > + config RISCV_VM_SV39 > + depends on 64BIT > + bool "RISC-V Sv39" > + help > + The Sv39 virtual memory system is a page-based > + address and page table format for RV64 systems. > + It specifies a translation between 39-bit virtual > + addresses and 40-bit physical addresses, via a The spec does not mention 40-bit physical addresses, but 56-bit. > + three-stage page table layout. > + config RISCV_VM_SV48 > + depends on 64BIT > + bool "RISC-V Sv48" > + help > + The Sv48 virtual memory system is a page-based > + address and page table format for RV64 systems. > + It specifies a translation between 48-bit virtual > + addresses and 49-bit physical addresses, via a ditto. > + four-stage page table layout. > + > +endchoice > + > + > choice > prompt "Maximum Physical Memory" > default MAXPHYSMEM_2GB if 32BIT > diff --git a/arch/riscv/include/asm/pgtable-32.h b/arch/riscv/include/asm/pgtable-32.h > index b0ab66e5fdb1..86d41a04735b 100644 > --- a/arch/riscv/include/asm/pgtable-32.h > +++ b/arch/riscv/include/asm/pgtable-32.h > @@ -6,6 +6,10 @@ > #ifndef _ASM_RISCV_PGTABLE_32_H > #define _ASM_RISCV_PGTABLE_32_H > > +#if !defined(CONFIG_RISCV_VM_SV32) > +#error Only Sv32 supported > +#endif > + > #include <asm-generic/pgtable-nopmd.h> > #include <linux/const.h> > > diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h > index 74630989006d..86935595115d 100644 > --- a/arch/riscv/include/asm/pgtable-64.h > +++ b/arch/riscv/include/asm/pgtable-64.h > @@ -6,6 +6,10 @@ > #ifndef _ASM_RISCV_PGTABLE_64_H > #define _ASM_RISCV_PGTABLE_64_H > > +#if !defined(CONFIG_RISCV_VM_SV39) > +#error Only Sv39 supported for now > +#endif > + > #include <linux/const.h> > > #define PGDIR_SHIFT 30 > -- Regards, Bin
On Sun, 28 Jul 2019, Bin Meng wrote: > The spec does not mention 40-bit physical addresses, but 56-bit. Thanks, agreed. Updated patch below - Paul From: Paul Walmsley <paul.walmsley@sifive.com> Date: Fri, 26 Jul 2019 10:21:11 -0700 Subject: [PATCH v2] riscv: kbuild: add virtual memory system selection The RISC-V specifications currently define three virtual memory translation systems: Sv32, Sv39, and Sv48. Sv32 is currently specific to 32-bit systems; Sv39 and Sv48 are currently specific to 64-bit systems. The current kernel only supports Sv32 and Sv39, but we'd like to start preparing for Sv48. As an initial step, allow the virtual memory translation system to be selected via kbuild, and stop the build if an option is selected that the kernel doen't currently support. This second version of the patch fixes some errors in the Kconfig description text, found by Bin Meng <bmeng.cn@gmail.com>. This patch currently has no functional impact. Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: Bin Meng <bmeng.cn@gmail.com> --- arch/riscv/Kconfig | 43 +++++++++++++++++++++++++++++ arch/riscv/include/asm/pgtable-32.h | 4 +++ arch/riscv/include/asm/pgtable-64.h | 4 +++ 3 files changed, 51 insertions(+) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 59a4727ecd6c..f5e76e25a91e 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -155,6 +155,49 @@ config MODULE_SECTIONS bool select HAVE_MOD_ARCH_SPECIFIC +choice + prompt "Virtual Memory System" + default RISCV_VM_SV32 if 32BIT + default RISCV_VM_SV39 if 64BIT + help + The RISC-V Instruction Set Manual Volume II: Privileged + Architecture defines several different "virtual memory + systems" which specify virtual and physical address formats + and the structure of page table entries. This determines + the amount of virtual address space present and how it is + translated into physical addresses. + + config RISCV_VM_SV32 + depends on 32BIT + bool "RISC-V Sv32" + help + The Sv32 virtual memory system is a page-based + address and page table format for RV32 systems. + It specifies a translation between 32-bit virtual + addresses and 33-bit physical addresses, via a + two-stage page table layout. + config RISCV_VM_SV39 + depends on 64BIT + bool "RISC-V Sv39" + help + The Sv39 virtual memory system is a page-based + address and page table format for RV64 systems. + It specifies a translation between 39-bit virtual + addresses and 56-bit physical addresses, via a + three-stage page table layout. + config RISCV_VM_SV48 + depends on 64BIT + bool "RISC-V Sv48" + help + The Sv48 virtual memory system is a page-based + address and page table format for RV64 systems. + It specifies a translation between 48-bit virtual + addresses and 56-bit physical addresses, via a + four-stage page table layout. + +endchoice + + choice prompt "Maximum Physical Memory" default MAXPHYSMEM_2GB if 32BIT diff --git a/arch/riscv/include/asm/pgtable-32.h b/arch/riscv/include/asm/pgtable-32.h index b0ab66e5fdb1..86d41a04735b 100644 --- a/arch/riscv/include/asm/pgtable-32.h +++ b/arch/riscv/include/asm/pgtable-32.h @@ -6,6 +6,10 @@ #ifndef _ASM_RISCV_PGTABLE_32_H #define _ASM_RISCV_PGTABLE_32_H +#if !defined(CONFIG_RISCV_VM_SV32) +#error Only Sv32 supported +#endif + #include <asm-generic/pgtable-nopmd.h> #include <linux/const.h> diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h index 74630989006d..86935595115d 100644 --- a/arch/riscv/include/asm/pgtable-64.h +++ b/arch/riscv/include/asm/pgtable-64.h @@ -6,6 +6,10 @@ #ifndef _ASM_RISCV_PGTABLE_64_H #define _ASM_RISCV_PGTABLE_64_H +#if !defined(CONFIG_RISCV_VM_SV39) +#error Only Sv39 supported for now +#endif + #include <linux/const.h> #define PGDIR_SHIFT 30
On Thu, Aug 1, 2019 at 3:37 AM Paul Walmsley <paul.walmsley@sifive.com> wrote: > > On Sun, 28 Jul 2019, Bin Meng wrote: > > > The spec does not mention 40-bit physical addresses, but 56-bit. > > Thanks, agreed. Updated patch below > > > - Paul > > From: Paul Walmsley <paul.walmsley@sifive.com> > Date: Fri, 26 Jul 2019 10:21:11 -0700 > Subject: [PATCH v2] riscv: kbuild: add virtual memory system selection > > The RISC-V specifications currently define three virtual memory > translation systems: Sv32, Sv39, and Sv48. Sv32 is currently specific > to 32-bit systems; Sv39 and Sv48 are currently specific to 64-bit > systems. The current kernel only supports Sv32 and Sv39, but we'd > like to start preparing for Sv48. As an initial step, allow the > virtual memory translation system to be selected via kbuild, and stop > the build if an option is selected that the kernel doen't currently > support. > > This second version of the patch fixes some errors in the Kconfig > description text, found by Bin Meng <bmeng.cn@gmail.com>. > > This patch currently has no functional impact. > > Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com> > Cc: Alexandre Ghiti <alex@ghiti.fr> > Cc: Bin Meng <bmeng.cn@gmail.com> > --- > arch/riscv/Kconfig | 43 +++++++++++++++++++++++++++++ > arch/riscv/include/asm/pgtable-32.h | 4 +++ > arch/riscv/include/asm/pgtable-64.h | 4 +++ > 3 files changed, 51 insertions(+) > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index 59a4727ecd6c..f5e76e25a91e 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -155,6 +155,49 @@ config MODULE_SECTIONS > bool > select HAVE_MOD_ARCH_SPECIFIC > > +choice > + prompt "Virtual Memory System" > + default RISCV_VM_SV32 if 32BIT > + default RISCV_VM_SV39 if 64BIT > + help > + The RISC-V Instruction Set Manual Volume II: Privileged > + Architecture defines several different "virtual memory > + systems" which specify virtual and physical address formats > + and the structure of page table entries. This determines > + the amount of virtual address space present and how it is > + translated into physical addresses. > + > + config RISCV_VM_SV32 > + depends on 32BIT > + bool "RISC-V Sv32" > + help > + The Sv32 virtual memory system is a page-based > + address and page table format for RV32 systems. > + It specifies a translation between 32-bit virtual > + addresses and 33-bit physical addresses, via a > + two-stage page table layout. > + config RISCV_VM_SV39 > + depends on 64BIT > + bool "RISC-V Sv39" > + help > + The Sv39 virtual memory system is a page-based > + address and page table format for RV64 systems. > + It specifies a translation between 39-bit virtual > + addresses and 56-bit physical addresses, via a > + three-stage page table layout. > + config RISCV_VM_SV48 > + depends on 64BIT > + bool "RISC-V Sv48" > + help > + The Sv48 virtual memory system is a page-based > + address and page table format for RV64 systems. > + It specifies a translation between 48-bit virtual > + addresses and 56-bit physical addresses, via a > + four-stage page table layout. > + > +endchoice > + > + > choice > prompt "Maximum Physical Memory" > default MAXPHYSMEM_2GB if 32BIT > diff --git a/arch/riscv/include/asm/pgtable-32.h b/arch/riscv/include/asm/pgtable-32.h > index b0ab66e5fdb1..86d41a04735b 100644 > --- a/arch/riscv/include/asm/pgtable-32.h > +++ b/arch/riscv/include/asm/pgtable-32.h > @@ -6,6 +6,10 @@ > #ifndef _ASM_RISCV_PGTABLE_32_H > #define _ASM_RISCV_PGTABLE_32_H > > +#if !defined(CONFIG_RISCV_VM_SV32) > +#error Only Sv32 supported > +#endif > + > #include <asm-generic/pgtable-nopmd.h> > #include <linux/const.h> > > diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h > index 74630989006d..86935595115d 100644 > --- a/arch/riscv/include/asm/pgtable-64.h > +++ b/arch/riscv/include/asm/pgtable-64.h > @@ -6,6 +6,10 @@ > #ifndef _ASM_RISCV_PGTABLE_64_H > #define _ASM_RISCV_PGTABLE_64_H > > +#if !defined(CONFIG_RISCV_VM_SV39) > +#error Only Sv39 supported for now > +#endif > + > #include <linux/const.h> > > #define PGDIR_SHIFT 30 > -- Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
On Fri, Jul 26, 2019 at 01:00:49PM -0700, Paul Walmsley wrote: > > The RISC-V specifications currently define three virtual memory > translation systems: Sv32, Sv39, and Sv48. Sv32 is currently specific > to 32-bit systems; Sv39 and Sv48 are currently specific to 64-bit > systems. The current kernel only supports Sv32 and Sv39, but we'd > like to start preparing for Sv48. As an initial step, allow the > virtual memory translation system to be selected via kbuild, and stop > the build if an option is selected that the kernel doen't currently > support. > > This patch currently has no functional impact. It cause the user to be able to select a config which thus won't build. So it is not just useless, which already is a reason not to merge it, but actively harmful, which is even worse. Even if we assume we want to implement Sv48 eventually (which seems to be a bit off), we need to make this a runtime choice and not a compile time one to not balloon the number of configs that distributions (and kernel developers) need to support.
On Fri, 2 Aug 2019, Christoph Hellwig wrote: > On Fri, Jul 26, 2019 at 01:00:49PM -0700, Paul Walmsley wrote: > > > > The RISC-V specifications currently define three virtual memory > > translation systems: Sv32, Sv39, and Sv48. Sv32 is currently specific > > to 32-bit systems; Sv39 and Sv48 are currently specific to 64-bit > > systems. The current kernel only supports Sv32 and Sv39, but we'd > > like to start preparing for Sv48. As an initial step, allow the > > virtual memory translation system to be selected via kbuild, and stop > > the build if an option is selected that the kernel doen't currently > > support. > > > > This patch currently has no functional impact. > > It cause the user to be able to select a config which thus won't build. > So it is not just useless, which already is a reason not to merge it, The rationale is to encourage others to start laying the groundwork for future Sv48 support. The immediate trigger for it was Alex's mmap randomization support patch series, which needs to set some Kconfig options differently depending on the selection of Sv32/39/48. > but actively harmful, which is even worse. Reflecting on this assertion, the only case that I could come up with is that randconfig or allyesconfig build testing could fail. Is this the case that you're thinking of, or is there a different one? If that's the one, I do agree that it would be best to avoid this case, and it looks like there's no obvious way to work around that issue. > Even if we assume we want to implement Sv48 eventually (which seems > to be a bit off), we need to make this a runtime choice and not a > compile time one to not balloon the number of configs that distributions > (and kernel developers) need to support. The expectation is that kernels that support multiple virtual memory system modes at runtime will probably incur either a performance or a memory layout penalty for doing so. So performance-sensitive embedded applications will select only the model that they use, while distribution kernels will likely take the performance hit for broader single-kernel support. - Paul
On Tue, Aug 06, 2019 at 05:02:03PM -0700, Paul Walmsley wrote: > The rationale is to encourage others to start laying the groundwork for > future Sv48 support. The immediate trigger for it was Alex's mmap > randomization support patch series, which needs to set some Kconfig > options differently depending on the selection of Sv32/39/48. Writing a formal todo list is much better encouragement than adding dead code. Th latter has a tendency of lingering around forever and actually hurting people. > > > but actively harmful, which is even worse. > > Reflecting on this assertion, the only case that I could come up with is > that randconfig or allyesconfig build testing could fail. Is this the > case that you're thinking of, or is there a different one? If that's the > one, I do agree that it would be best to avoid this case, and it looks > like there's no obvious way to work around that issue. randconfig or just a user thinking bigger is better and picking it. > > Even if we assume we want to implement Sv48 eventually (which seems > > to be a bit off), we need to make this a runtime choice and not a > > compile time one to not balloon the number of configs that distributions > > (and kernel developers) need to support. > > The expectation is that kernels that support multiple virtual memory > system modes at runtime will probably incur either a performance or a > memory layout penalty for doing so. So performance-sensitive embedded > applications will select only the model that they use, while distribution > kernels will likely take the performance hit for broader single-kernel > support. Even if we want to support Sv39 only or Sv39+Sv39 the choice in the patch doesn't make any sense. So better do the whole thing when its ready than doing false "groundwork".
On 8/7/19 7:42 AM, Christoph Hellwig wrote: > On Tue, Aug 06, 2019 at 05:02:03PM -0700, Paul Walmsley wrote: >> The rationale is to encourage others to start laying the groundwork for >> future Sv48 support. The immediate trigger for it was Alex's mmap >> randomization support patch series, which needs to set some Kconfig >> options differently depending on the selection of Sv32/39/48. > Writing a formal todo list is much better encouragement than adding > dead code. Th latter has a tendency of lingering around forever and > actually hurting people. > >>> but actively harmful, which is even worse. >> Reflecting on this assertion, the only case that I could come up with is >> that randconfig or allyesconfig build testing could fail. Is this the >> case that you're thinking of, or is there a different one? If that's the >> one, I do agree that it would be best to avoid this case, and it looks >> like there's no obvious way to work around that issue. > randconfig or just a user thinking bigger is better and picking it. > >>> Even if we assume we want to implement Sv48 eventually (which seems >>> to be a bit off), we need to make this a runtime choice and not a >>> compile time one to not balloon the number of configs that distributions >>> (and kernel developers) need to support. >> The expectation is that kernels that support multiple virtual memory >> system modes at runtime will probably incur either a performance or a >> memory layout penalty for doing so. So performance-sensitive embedded >> applications will select only the model that they use, while distribution >> kernels will likely take the performance hit for broader single-kernel >> support. > Even if we want to support Sv39 only or Sv39+Sv39 the choice in the > patch doesn't make any sense. So better do the whole thing when its > ready than doing false "groundwork". I took a look at how x86 deals with 5-level page table: it allows to handle 5-level and 4-level at runtime by folding the last page table level (cf Documentation/x86/x86_64/5level-paging.rst). So we might want to be able to do the same and deal with that at runtime. Regarding my series about mmap, x86 does not care about the width of the the address space and sets values of ARCH_MMAP_RND_BITS_MIN/MAX based on 32bit or 64bit (but then does not respect the magic formula as in arm64). And FYI my series and your patch are already in linux-next. Thanks, Alex > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Wed, Aug 07, 2019 at 09:04:40AM +0200, Alexandre Ghiti wrote: > I took a look at how x86 deals with 5-level page table: it allows to handle > 5-level and 4-level at runtime by folding the last page table level (cf > Documentation/x86/x86_64/5level-paging.rst). So we might want to be able to > do the same and deal with that at runtime. Yes, following the X86_5LEVEL model is the right thing.
On Wed, 07 Aug 2019 08:12:30 PDT (-0700), Christoph Hellwig wrote: > On Wed, Aug 07, 2019 at 09:04:40AM +0200, Alexandre Ghiti wrote: >> I took a look at how x86 deals with 5-level page table: it allows to handle >> 5-level and 4-level at runtime by folding the last page table level (cf >> Documentation/x86/x86_64/5level-paging.rst). So we might want to be able to >> do the same and deal with that at runtime. > > Yes, following the X86_5LEVEL model is the right thing. I poked around a bit with this last night, but our paging implemention is super ugly so it'd be better to clean all that up first. No idea when I'll have time to do so...
On Wed, 7 Aug 2019, Alexandre Ghiti wrote:
> And FYI my series and your patch are already in linux-next.
Yes, I agree with Christoph that it would be preferable not to break
randconfig/allyesconfig. So if you don't mind, could you respin the
RISC-V patch to drop the Sv48 portion, and simply assume Sv39 for RV64 as
we do for the rest of the RISC-V kernel code? We can always add Sv48
back in later.
If you agree, then once you do that, I'll ask Andrew to drop the RISC-V
Kbuild patch that he's carrying.
- Paul
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 59a4727ecd6c..8ef64fe2c2b3 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -155,6 +155,49 @@ config MODULE_SECTIONS bool select HAVE_MOD_ARCH_SPECIFIC +choice + prompt "Virtual Memory System" + default RISCV_VM_SV32 if 32BIT + default RISCV_VM_SV39 if 64BIT + help + The RISC-V Instruction Set Manual Volume II: Privileged + Architecture defines several different "virtual memory + systems" which specify virtual and physical address formats + and the structure of page table entries. This determines + the amount of virtual address space present and how it is + translated into physical addresses. + + config RISCV_VM_SV32 + depends on 32BIT + bool "RISC-V Sv32" + help + The Sv32 virtual memory system is a page-based + address and page table format for RV32 systems. + It specifies a translation between 32-bit virtual + addresses and 33-bit physical addresses, via a + two-stage page table layout. + config RISCV_VM_SV39 + depends on 64BIT + bool "RISC-V Sv39" + help + The Sv39 virtual memory system is a page-based + address and page table format for RV64 systems. + It specifies a translation between 39-bit virtual + addresses and 40-bit physical addresses, via a + three-stage page table layout. + config RISCV_VM_SV48 + depends on 64BIT + bool "RISC-V Sv48" + help + The Sv48 virtual memory system is a page-based + address and page table format for RV64 systems. + It specifies a translation between 48-bit virtual + addresses and 49-bit physical addresses, via a + four-stage page table layout. + +endchoice + + choice prompt "Maximum Physical Memory" default MAXPHYSMEM_2GB if 32BIT diff --git a/arch/riscv/include/asm/pgtable-32.h b/arch/riscv/include/asm/pgtable-32.h index b0ab66e5fdb1..86d41a04735b 100644 --- a/arch/riscv/include/asm/pgtable-32.h +++ b/arch/riscv/include/asm/pgtable-32.h @@ -6,6 +6,10 @@ #ifndef _ASM_RISCV_PGTABLE_32_H #define _ASM_RISCV_PGTABLE_32_H +#if !defined(CONFIG_RISCV_VM_SV32) +#error Only Sv32 supported +#endif + #include <asm-generic/pgtable-nopmd.h> #include <linux/const.h> diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h index 74630989006d..86935595115d 100644 --- a/arch/riscv/include/asm/pgtable-64.h +++ b/arch/riscv/include/asm/pgtable-64.h @@ -6,6 +6,10 @@ #ifndef _ASM_RISCV_PGTABLE_64_H #define _ASM_RISCV_PGTABLE_64_H +#if !defined(CONFIG_RISCV_VM_SV39) +#error Only Sv39 supported for now +#endif + #include <linux/const.h> #define PGDIR_SHIFT 30
The RISC-V specifications currently define three virtual memory translation systems: Sv32, Sv39, and Sv48. Sv32 is currently specific to 32-bit systems; Sv39 and Sv48 are currently specific to 64-bit systems. The current kernel only supports Sv32 and Sv39, but we'd like to start preparing for Sv48. As an initial step, allow the virtual memory translation system to be selected via kbuild, and stop the build if an option is selected that the kernel doen't currently support. This patch currently has no functional impact. Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com> Cc: Alexandre Ghiti <alex@ghiti.fr> --- arch/riscv/Kconfig | 43 +++++++++++++++++++++++++++++ arch/riscv/include/asm/pgtable-32.h | 4 +++ arch/riscv/include/asm/pgtable-64.h | 4 +++ 3 files changed, 51 insertions(+)