diff mbox series

[v6,4/4] RISC-V: mm: Document mmap changes

Message ID 20230714165508.94561-5-charlie@rivosinc.com (mailing list archive)
State Superseded
Headers show
Series RISC-V: mm: Make SV48 the default address space | expand

Checks

Context Check Description
conchuod/cover_letter success Series has a cover letter
conchuod/tree_selection success Guessed tree name to be for-next at HEAD 471aba2e4760
conchuod/fixes_present success Fixes tag not required for -next series
conchuod/maintainers_pattern success MAINTAINERS pattern errors before the patch: 4 and now 4
conchuod/verify_signedoff success Signed-off-by tag matches author and committer
conchuod/kdoc success Errors and warnings before: 0 this patch: 0
conchuod/build_rv64_clang_allmodconfig success Errors and warnings before: 9 this patch: 9
conchuod/module_param success Was 0 now: 0
conchuod/build_rv64_gcc_allmodconfig success Errors and warnings before: 9 this patch: 9
conchuod/build_rv32_defconfig success Build OK
conchuod/dtb_warn_rv64 success Errors and warnings before: 3 this patch: 3
conchuod/header_inline success No static functions without inline keyword in header files
conchuod/checkpatch success total: 0 errors, 0 warnings, 0 checks, 25 lines checked
conchuod/build_rv64_nommu_k210_defconfig success Build OK
conchuod/verify_fixes success No Fixes tag
conchuod/build_rv64_nommu_virt_defconfig success Build OK

Commit Message

Charlie Jenkins July 14, 2023, 4:54 p.m. UTC
The behavior of mmap is modified with this patch series, so explain the
changes to the mmap hint address behavior.

Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
---
 Documentation/riscv/vm-layout.rst | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

Comments

Alexandre Ghiti July 20, 2023, 6:59 a.m. UTC | #1
On Fri, Jul 14, 2023 at 6:56 PM Charlie Jenkins <charlie@rivosinc.com> wrote:
>
> The behavior of mmap is modified with this patch series, so explain the
> changes to the mmap hint address behavior.
>
> Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
> ---
>  Documentation/riscv/vm-layout.rst | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
>
> diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst
> index 5462c84f4723..892412b91300 100644
> --- a/Documentation/riscv/vm-layout.rst
> +++ b/Documentation/riscv/vm-layout.rst
> @@ -133,3 +133,25 @@ RISC-V Linux Kernel SV57
>     ffffffff00000000 |  -4     GB | ffffffff7fffffff |    2 GB | modules, BPF
>     ffffffff80000000 |  -2     GB | ffffffffffffffff |    2 GB | kernel
>    __________________|____________|__________________|_________|____________________________________________________________
> +
> +
> +Userspace VAs
> +--------------------
> +To maintain compatibility with software that relies on the VA space with a
> +maximum of 48 bits the kernel will, by default, return virtual addresses to
> +userspace from a 48-bit range (sv48). This default behavior is achieved by
> +passing 0 into the hint address parameter of mmap. On CPUs with an address space
> +smaller than sv48, the CPU maximum supported address space will be the default.
> +
> +Software can "opt-in" to receiving VAs from another VA space by providing
> +a hint address to mmap. A call to mmap is guaranteed to return an address
> +that will not override the unset left-aligned bits in the hint address,
> +unless there is no space left in the address space. If there is no space
> +available in the requested address space, an address in the next smallest
> +available address space will be returned.
> +
> +For example, in order to obtain 48-bit VA space, a hint address greater than
> +:code:`1 << 38` must be provided.

Is this correct? Shouldn't the hint be strictly greater than the
address space it targets? In patch 1, you state that "A hint address
passed to mmap will cause the largest address space that fits entirely
into the hint to be used", it seems contradictory to me.

> Note that this is 38 due to sv39 userspace
> +ending at :code:`1 << 38` and the addresses beyond this are reserved for the
> +kernel. Similarly, to obtain 57-bit VA space addresses, a hint address greater
> +than or equal to :code:`1 << 47` must be provided.
> --
> 2.41.0
>
Charlie Jenkins July 26, 2023, 1:52 p.m. UTC | #2
On Thu, Jul 20, 2023 at 08:59:12AM +0200, Alexandre Ghiti wrote:
> On Fri, Jul 14, 2023 at 6:56 PM Charlie Jenkins <charlie@rivosinc.com> wrote:
> >
> > The behavior of mmap is modified with this patch series, so explain the
> > changes to the mmap hint address behavior.
> >
> > Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
> > ---
> >  Documentation/riscv/vm-layout.rst | 22 ++++++++++++++++++++++
> >  1 file changed, 22 insertions(+)
> >
> > diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst
> > index 5462c84f4723..892412b91300 100644
> > --- a/Documentation/riscv/vm-layout.rst
> > +++ b/Documentation/riscv/vm-layout.rst
> > @@ -133,3 +133,25 @@ RISC-V Linux Kernel SV57
> >     ffffffff00000000 |  -4     GB | ffffffff7fffffff |    2 GB | modules, BPF
> >     ffffffff80000000 |  -2     GB | ffffffffffffffff |    2 GB | kernel
> >    __________________|____________|__________________|_________|____________________________________________________________
> > +
> > +
> > +Userspace VAs
> > +--------------------
> > +To maintain compatibility with software that relies on the VA space with a
> > +maximum of 48 bits the kernel will, by default, return virtual addresses to
> > +userspace from a 48-bit range (sv48). This default behavior is achieved by
> > +passing 0 into the hint address parameter of mmap. On CPUs with an address space
> > +smaller than sv48, the CPU maximum supported address space will be the default.
> > +
> > +Software can "opt-in" to receiving VAs from another VA space by providing
> > +a hint address to mmap. A call to mmap is guaranteed to return an address
> > +that will not override the unset left-aligned bits in the hint address,
> > +unless there is no space left in the address space. If there is no space
> > +available in the requested address space, an address in the next smallest
> > +available address space will be returned.
> > +
> > +For example, in order to obtain 48-bit VA space, a hint address greater than
> > +:code:`1 << 38` must be provided.
> 
> Is this correct? Shouldn't the hint be strictly greater than the
> address space it targets? In patch 1, you state that "A hint address
> passed to mmap will cause the largest address space that fits entirely
> into the hint to be used", it seems contradictory to me.
> 
That is a mistake, it should have a hint address greater than 1 << 47. I
will fix up the wording here.
> > Note that this is 38 due to sv39 userspace
> > +ending at :code:`1 << 38` and the addresses beyond this are reserved for the
> > +kernel. Similarly, to obtain 57-bit VA space addresses, a hint address greater
> > +than or equal to :code:`1 << 47` must be provided.
> > --
> > 2.41.0
> >
diff mbox series

Patch

diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst
index 5462c84f4723..892412b91300 100644
--- a/Documentation/riscv/vm-layout.rst
+++ b/Documentation/riscv/vm-layout.rst
@@ -133,3 +133,25 @@  RISC-V Linux Kernel SV57
    ffffffff00000000 |  -4     GB | ffffffff7fffffff |    2 GB | modules, BPF
    ffffffff80000000 |  -2     GB | ffffffffffffffff |    2 GB | kernel
   __________________|____________|__________________|_________|____________________________________________________________
+
+
+Userspace VAs
+--------------------
+To maintain compatibility with software that relies on the VA space with a
+maximum of 48 bits the kernel will, by default, return virtual addresses to
+userspace from a 48-bit range (sv48). This default behavior is achieved by
+passing 0 into the hint address parameter of mmap. On CPUs with an address space
+smaller than sv48, the CPU maximum supported address space will be the default.
+
+Software can "opt-in" to receiving VAs from another VA space by providing
+a hint address to mmap. A call to mmap is guaranteed to return an address
+that will not override the unset left-aligned bits in the hint address,
+unless there is no space left in the address space. If there is no space
+available in the requested address space, an address in the next smallest
+available address space will be returned.
+
+For example, in order to obtain 48-bit VA space, a hint address greater than
+:code:`1 << 38` must be provided. Note that this is 38 due to sv39 userspace
+ending at :code:`1 << 38` and the addresses beyond this are reserved for the
+kernel. Similarly, to obtain 57-bit VA space addresses, a hint address greater
+than or equal to :code:`1 << 47` must be provided.