Re: [RFC PATCH v2 01/31] Documentation: kvx: Add basic documentation
On Wed, Jan 25, 2023 at 07:28:20PM +0100, Jules Maselbas wrote: > Hi Bagas, > > Thanks for taking your time and effort to improve the documentation. > We not only need to clean the documention syntax and wording but also > its content. I am tempted to apply all your proposed changes first and > then work on improving and correcting the documentation. > > However I am not very sure on how to integrate your changes and give > proper contribution attributions. Any insights on this would be greatly > appreciated. > Hi Jules, The reword diff can be squashed into the doc patch (here, [01/31]). For the attribution, since the reword is significant, Co-developed-by: Bagas Sanjaya Signed-off-by: Bagas Sanjaya Thanks. -- An old man doll... just what I always wanted! - Clara signature.asc Description: PGP signature -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [RFC PATCH v2 01/31] Documentation: kvx: Add basic documentation
Hi Bagas, Thanks for taking your time and effort to improve the documentation. We not only need to clean the documention syntax and wording but also its content. I am tempted to apply all your proposed changes first and then work on improving and correcting the documentation. However I am not very sure on how to integrate your changes and give proper contribution attributions. Any insights on this would be greatly appreciated. Thanks -- Jules -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [RFC PATCH v2 01/31] Documentation: kvx: Add basic documentation
On Fri, Jan 20, 2023 at 03:09:32PM +0100, Yann Sionneau wrote: > Add some documentation for the kvx architecture and its Linux port. "Document the kvx Linux port. The documentation covers design decision, memory management, exception handling, and SMP." > Documentation/arch.rst | 1 + > Documentation/kvx/index.rst | 17 ++ > Documentation/kvx/kvx-exceptions.rst | 256 > Documentation/kvx/kvx-iommu.rst | 191 ++ > Documentation/kvx/kvx-mmu.rst| 287 +++ > Documentation/kvx/kvx-smp.rst| 39 > Documentation/kvx/kvx.rst| 273 + > 7 files changed, 1064 insertions(+) > create mode 100644 Documentation/kvx/index.rst > create mode 100644 Documentation/kvx/kvx-exceptions.rst > create mode 100644 Documentation/kvx/kvx-iommu.rst > create mode 100644 Documentation/kvx/kvx-mmu.rst > create mode 100644 Documentation/kvx/kvx-smp.rst > create mode 100644 Documentation/kvx/kvx.rst > The documentation reads a rather odd and unclear to me, so I have to write the improv: >8 diff --git a/Documentation/kvx/kvx-exceptions.rst b/Documentation/kvx/kvx-exceptions.rst index 5e01e934192f13..efb162edadb6a0 100644 --- a/Documentation/kvx/kvx-exceptions.rst +++ b/Documentation/kvx/kvx-exceptions.rst @@ -1,9 +1,9 @@ -== -Exceptions -== += +Exception handling in kvx += On kvx, handlers are set using ``$ev`` (exception vector) register which -specifies a base address. An offset is added to ``$ev`` upon exception +specifies the base address. An offset is added to ``$ev`` upon exception and the result is used as the new ``$pc``. The offset depends on which exception vector the cpu wants to jump to: @@ -35,12 +35,13 @@ Interrupts and traps are serviced similarly, ie: - Jump to handler - Save all registers - - Prepare the call (do_IRQ or trap_handler) + - Prepare the call (``do_IRQ`` or ``trap_handler``) - restore all registers - return from exception -entry.S file is (as for other architectures) the entry point into the kernel. -It contains all assembly routines related to interrupts/traps/syscall. +As in other architectures, ``entry.S`` file is the entry point into the +kernel. It contains all assembly routines related to +interrupts/traps/syscall. Syscall handling @@ -51,7 +52,7 @@ a syscall from the kernel. Syscalls are handled differently than interrupts/exceptions. From an ABI point of view, syscalls are like function calls: any caller-saved register -can be clobbered by the syscall. However, syscall parameters are passed +can be clobberred by the syscall. However, syscall parameters are passed using registers r0 through r7. These registers must be preserved to avoid clobberring them before the actual syscall function. @@ -59,23 +60,23 @@ On syscall from userspace (``scall`` instruction), the processor will put the syscall number in $es.sn and switch from user to kernel privilege mode. ``kvx_syscall_handler`` will be called in kernel mode. -The following steps are then taken: +Below is the path when executing syscall: - 1. Switch to kernel stack - 2. Extract syscall number - 3. If the syscall number is bogus, set the syscall function to ``sys_ni_syscall`` - 4. If tracing is enabled + 1. Switch to kernel stack. + 2. Extract syscall number. If it is bogus, set the syscall function to +``sys_ni_syscall``. + 3. If tracing is enabled: -- Jump to ``trace_syscall_enter`` +- Jump to ``trace_syscall_enter``. - Save syscall arguments (``r0`` -> ``r7``) on stack in ``pt_regs``. - Call ``do_trace_syscall_enter`` function. - 5. Restore syscall arguments since they have been modified by C call - 6. Call the syscall function - 7. Save ``$r0`` in ``pt_regs`` since it can be clobberred afterward - 8. If tracing is enabled, call ``trace_syscall_exit``. - 9. Call ``work_pending`` - 10. Return to user ! + 4. Restore syscall arguments since they have been modified by C call. + 5. Call the syscall function. + 6. Save ``$r0`` in ``pt_regs`` since it can be clobberred afterward. + 7. If tracing is enabled, call ``trace_syscall_exit``. + 8. Call ``work_pending``. + 9. Return to user. The trace call is handled out of the fast path. All slow path handling is done in another part of code to avoid messing with the cache. @@ -84,25 +85,25 @@ Signals --- Signals are handled when exiting kernel before returning to user. -When handling a signal, the path is the following: +When handling a signal, the execution path is: - 1. User application is executing normally -Then any exception happens (syscall, interrupt, trap) - 2. The exception handling path is taken -and before returning to user, pending signals are checked - 3. Signal are handled by ``do_signal``. -Registers are saved and a special part of the stack is modified + 1.
Re: [RFC PATCH v2 01/31] Documentation: kvx: Add basic documentation
Hi, While reviewing kvx-mmu.rst I've spotted several places where the documentation does not match the code, please make sure that the documentation in this patch actually reflects what the code is doing. Also, sectioning looked a bit strange to me, make sure to take a look at the generated html and see if it is rendered as intended. On Fri, Jan 20, 2023 at 03:09:32PM +0100, Yann Sionneau wrote: > Add some documentation for the kvx architecture and its Linux port. > > Co-developed-by: Clement Leger > Signed-off-by: Clement Leger > Co-developed-by: Jules Maselbas > Signed-off-by: Jules Maselbas > Co-developed-by: Guillaume Thouvenin > Signed-off-by: Guillaume Thouvenin > Signed-off-by: Yann Sionneau > --- > > Notes: > V1 -> V2: > - converted to .rst, typos and formatting fixes > - reword few paragraphs > > Documentation/arch.rst | 1 + > Documentation/kvx/index.rst | 17 ++ > Documentation/kvx/kvx-exceptions.rst | 256 > Documentation/kvx/kvx-iommu.rst | 191 ++ > Documentation/kvx/kvx-mmu.rst| 287 +++ > Documentation/kvx/kvx-smp.rst| 39 > Documentation/kvx/kvx.rst| 273 + > 7 files changed, 1064 insertions(+) > create mode 100644 Documentation/kvx/index.rst > create mode 100644 Documentation/kvx/kvx-exceptions.rst > create mode 100644 Documentation/kvx/kvx-iommu.rst > create mode 100644 Documentation/kvx/kvx-mmu.rst > create mode 100644 Documentation/kvx/kvx-smp.rst > create mode 100644 Documentation/kvx/kvx.rst > > diff --git a/Documentation/arch.rst b/Documentation/arch.rst > index 41a66a8b38e4..1ccda8ef6eef 100644 > --- a/Documentation/arch.rst > +++ b/Documentation/arch.rst > @@ -13,6 +13,7 @@ implementation. > arm/index > arm64/index > ia64/index > + kvx/index > loongarch/index > m68k/index > mips/index ... > diff --git a/Documentation/kvx/kvx-mmu.rst b/Documentation/kvx/kvx-mmu.rst > new file mode 100644 > index ..b7186331396c > --- /dev/null > +++ b/Documentation/kvx/kvx-mmu.rst > @@ -0,0 +1,287 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +=== > +MMU > +=== > + > +Virtual addresses are on 41 bits for kvx when using 64-bit mode. There is only 64-bit support at the moment, so no need to mention it. > +To differentiate kernel from user space, we use the high order bit > +(bit 40). When bit 40 is set, then the higher remaining bits must also be > +set to 1. The virtual address must be extended with 1 when the bit 40 is set, > +if not the address must be zero extended. Bit 40 is set for kernel space > +mappings and not set for user space mappings. I'd reorder this paragraph to first mention that bit 40 is set for kernel space and then write about sign extension. > + > +Memory Map > +-- > + > +In Linux physical memories are arranged into banks according to the cost of > an > +access in term of distance to a memory. As we are UMA architecture we only > have > +one bank and thus one node. > + > +A node is divided into several kind of zone. For example if DMA can only > access > +a specific area in the physical memory we will define a ZONE_DMA for this > purpose. > +In our case we are considering that DMA can access all DDR so we don't have > a specific > +zone for this. On 64 bit architecture all DDR can be mapped in virtual > kernel space > +so there is no need for a ZONE_HIGHMEM. That means that in our case there is > +only one ZONE_NORMAL. This will be updated if DMA cannot access all memory. These two paragraphs have nothing to do with the virtual memory map. Please drop them. > + > +Currently, the memory mapping is the following for 4KB page: > + > + === == === > == > + StartEnd Attr SizeName > + === == === > == > + 003F ---256GBUser > + 0040 007F ---256GB MMAP > + 0080 FF7F ------ Gap > + FF80 ---512GBKernel > + FF80 FF8F RWX64GB Direct > Map > + FF90 FF90 3FFF RWX1GB Vmalloc > + FF90 4000 RW 447GB Free area > + === == === > == > + > +Enable the MMU > +-- > + > +All kernel functions and symbols are in virtual memory except for kvx_start() > +function which is loaded at 0x0 in physical memory. > +To be able to switch from physical addresses to virtual addresses we choose > to > +setup the TLB at the very beginning of the boot process to be able to map >
[RFC PATCH v2 01/31] Documentation: kvx: Add basic documentation
Add some documentation for the kvx architecture and its Linux port. Co-developed-by: Clement Leger Signed-off-by: Clement Leger Co-developed-by: Jules Maselbas Signed-off-by: Jules Maselbas Co-developed-by: Guillaume Thouvenin Signed-off-by: Guillaume Thouvenin Signed-off-by: Yann Sionneau --- Notes: V1 -> V2: - converted to .rst, typos and formatting fixes - reword few paragraphs Documentation/arch.rst | 1 + Documentation/kvx/index.rst | 17 ++ Documentation/kvx/kvx-exceptions.rst | 256 Documentation/kvx/kvx-iommu.rst | 191 ++ Documentation/kvx/kvx-mmu.rst| 287 +++ Documentation/kvx/kvx-smp.rst| 39 Documentation/kvx/kvx.rst| 273 + 7 files changed, 1064 insertions(+) create mode 100644 Documentation/kvx/index.rst create mode 100644 Documentation/kvx/kvx-exceptions.rst create mode 100644 Documentation/kvx/kvx-iommu.rst create mode 100644 Documentation/kvx/kvx-mmu.rst create mode 100644 Documentation/kvx/kvx-smp.rst create mode 100644 Documentation/kvx/kvx.rst diff --git a/Documentation/arch.rst b/Documentation/arch.rst index 41a66a8b38e4..1ccda8ef6eef 100644 --- a/Documentation/arch.rst +++ b/Documentation/arch.rst @@ -13,6 +13,7 @@ implementation. arm/index arm64/index ia64/index + kvx/index loongarch/index m68k/index mips/index diff --git a/Documentation/kvx/index.rst b/Documentation/kvx/index.rst new file mode 100644 index ..0bac597b5fbe --- /dev/null +++ b/Documentation/kvx/index.rst @@ -0,0 +1,17 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=== +Kalray kvx Architecture +=== + +.. toctree:: + :maxdepth: 2 + :numbered: + + kvx + kvx-exceptions + kvx-smp + kvx-mmu + kvx-iommu + + diff --git a/Documentation/kvx/kvx-exceptions.rst b/Documentation/kvx/kvx-exceptions.rst new file mode 100644 index ..5e01e934192f --- /dev/null +++ b/Documentation/kvx/kvx-exceptions.rst @@ -0,0 +1,256 @@ +== +Exceptions +== + +On kvx, handlers are set using ``$ev`` (exception vector) register which +specifies a base address. An offset is added to ``$ev`` upon exception +and the result is used as the new ``$pc``. +The offset depends on which exception vector the cpu wants to jump to: + + == = + ``$ev + 0x00`` debug + ``$ev + 0x40`` trap + ``$ev + 0x80`` interrupt + ``$ev + 0xc0`` syscall + == = + +Then, handlers are laid in the following order:: + + _ +| | +| Syscall | +|_| +| | +| Interrupts | +|_| +| | +|Traps| +|_| +| | ^ +|Debug| | Stride +BASE -> |_| v + + +Interrupts and traps are serviced similarly, ie: + + - Jump to handler + - Save all registers + - Prepare the call (do_IRQ or trap_handler) + - restore all registers + - return from exception + +entry.S file is (as for other architectures) the entry point into the kernel. +It contains all assembly routines related to interrupts/traps/syscall. + +Syscall handling + + +When executing a syscall, it must be done using ``scall $r6`` where ``$r6`` +contains the syscall number. This convention allows to modify and restart +a syscall from the kernel. + +Syscalls are handled differently than interrupts/exceptions. From an ABI +point of view, syscalls are like function calls: any caller-saved register +can be clobbered by the syscall. However, syscall parameters are passed +using registers r0 through r7. These registers must be preserved to avoid +clobberring them before the actual syscall function. + +On syscall from userspace (``scall`` instruction), the processor will put +the syscall number in $es.sn and switch from user to kernel privilege +mode. ``kvx_syscall_handler`` will be called in kernel mode. + +The following steps are then taken: + + 1. Switch to kernel stack + 2. Extract syscall number + 3. If the syscall number is bogus, set the syscall function to ``sys_ni_syscall`` + 4. If tracing is enabled + +- Jump to ``trace_syscall_enter`` +- Save syscall arguments (``r0`` -> ``r7``) on stack in ``pt_regs``. +- Call ``do_trace_syscall_enter`` function. + + 5. Restore syscall arguments since they have been modified by C call + 6. Call the syscall function + 7. Save ``$r0`` in ``pt_regs`` since it can be clobberred afterward + 8. If tracing is enabled, call ``trace_syscall_exit``. + 9. Call ``work_pending`` + 10. Return to user ! + +The trace call is handled out of the fast path. All slow path handling +is done in another part of code to avoid messing with the cache. + +Signals +--- + +Signals are handled when exiting
