[PATCH v2] Documentation: riscv: Document the sv57 VM layout

[Alexandre Ghiti]

Hi Björn,

On 11/18/22 18:15, Björn Töpel wrote:
> From: Björn Töpel <bjorn at rivosinc.com>
>
> RISC-V has been supporting the "sv57" address translation mode for a
> while, but is has not been added to the VM layout documentation. Let
> us fix that.
>
> Signed-off-by: Björn Töpel <bjorn at rivosinc.com>
> ---
> v2: * Cosmestics (Alex)
>      * Corrected kasan address (Alex)
> ---
>   Documentation/riscv/vm-layout.rst | 36 +++++++++++++++++++++++++++++++
>   1 file changed, 36 insertions(+)
>
> diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst
> index 5b36e45fef60..3be44e74ec5d 100644
> --- a/Documentation/riscv/vm-layout.rst
> +++ b/Documentation/riscv/vm-layout.rst
> @@ -97,3 +97,39 @@ RISC-V Linux Kernel SV48
>      ffffffff00000000 |   -4    GB | ffffffff7fffffff |    2 GB | modules, BPF
>      ffffffff80000000 |   -2    GB | ffffffffffffffff |    2 GB | kernel
>     __________________|____________|__________________|_________|____________________________________________________________
> +
> +
> +RISC-V Linux Kernel SV57
> +------------------------
> +
> +::
> +
> + ========================================================================================================================
> +      Start addr    |   Offset   |     End addr     |  Size   | VM area description
> + ========================================================================================================================
> +                    |            |                  |         |
> +   0000000000000000 |   0        | 00ffffffffffffff |   64 PB | user-space virtual memory, different per mm
> +  __________________|____________|__________________|_________|___________________________________________________________
> +                    |            |                  |         |
> +   0100000000000000 | +64     PB | feffffffffffffff | ~16K PB | ... huge, almost 64 bits wide hole of non-canonical
> +                    |            |                  |         | virtual memory addresses up to the -64 PB
> +                    |            |                  |         | starting offset of kernel mappings.
> +  __________________|____________|__________________|_________|___________________________________________________________
> +                                                              |
> +                                                              | Kernel-space virtual memory, shared between all processes:
> +  ____________________________________________________________|___________________________________________________________
> +                    |            |                  |         |
> +   ff1bfffffee00000 | -57     PB | ff1bfffffeffffff |    2 MB | fixmap
> +   ff1bffffff000000 | -57     PB | ff1bffffffffffff |   16 MB | PCI io
> +   ff1c000000000000 | -57     PB | ff1fffffffffffff |    1 PB | vmemmap
> +   ff20000000000000 | -56     PB | ff5fffffffffffff |   16 PB | vmalloc/ioremap space
> +   ff60000000000000 | -40     PB | ffdeffffffffffff |   32 PB | direct mapping of all physical memory
> +   ffdf000000000000 |  -8     PB | fffffffeffffffff |    8 PB | kasan
> +  __________________|____________|__________________|_________|____________________________________________________________
> +                                                              |
> +                                                              | Identical layout to the 39-bit one from here on:
> +  ____________________________________________________________|____________________________________________________________
> +                    |            |                  |         |
> +   ffffffff00000000 |  -4     GB | ffffffff7fffffff |    2 GB | modules, BPF
> +   ffffffff80000000 |  -2     GB | ffffffffffffffff |    2 GB | kernel
> +  __________________|____________|__________________|_________|____________________________________________________________


Thanks for the corrections, this looks great to me now, you can add:

Reviewed-by: Alexandre Ghiti <alexghiti at rivosinc.com>

Thanks,

Alex