riscv: kbuild: add virtual memory system selection
diff mbox series

Message ID alpine.DEB.2.21.9999.1907261259420.26670@viisi.sifive.com
State New, archived
Headers show
Series
  • riscv: kbuild: add virtual memory system selection
Related show

Commit Message

Paul Walmsley July 26, 2019, 8 p.m. UTC
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(+)

Comments

Bin Meng July 28, 2019, 1:38 p.m. UTC | #1
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
Paul Walmsley July 31, 2019, 7:37 p.m. UTC | #2
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
Bin Meng Aug. 1, 2019, 8:56 a.m. UTC | #3
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>
Christoph Hellwig Aug. 2, 2019, 8:44 a.m. UTC | #4
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.
Paul Walmsley Aug. 7, 2019, 12:02 a.m. UTC | #5
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
Christoph Hellwig Aug. 7, 2019, 5:42 a.m. UTC | #6
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".
Alex Ghiti Aug. 7, 2019, 7:04 a.m. UTC | #7
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
Christoph Hellwig Aug. 7, 2019, 3:12 p.m. UTC | #8
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.
Palmer Dabbelt Aug. 7, 2019, 4:20 p.m. UTC | #9
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...
Paul Walmsley Aug. 7, 2019, 4:42 p.m. UTC | #10
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

Patch
diff mbox series

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