Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Arm64 kernelmode #277

Merged
merged 24 commits into from
Sep 12, 2024
Merged

Arm64 kernelmode #277

merged 24 commits into from
Sep 12, 2024

Conversation

pussuw
Copy link

@pussuw pussuw commented Sep 4, 2024

Just for self to hold code safely, PR created so can use github split diff view

pussuw and others added 12 commits September 5, 2024 12:48
Why? Because this allows optimizing the user system call path in such
a way that the parameter registers don't have to be read from the saved
integer register context when the system call is executed.
Make it possible to define arguments for barriers
This is the initial version for kernel mode build on the arm64 platform.
It works much in the same way as the risc-v implementation so any
highlights can be read from there.

Features that have been tested working:
- Creating address environments
- Loading init (nsh) from elf file
- Booting to nsh
- Starting other processes from nsh
- ostest runs to completion

Features that are not tested / do not work:
- SHM / shared memory support
- Kernel memory mapping (MM_KMAP)
- fork/vfork

An example qemu target is provided as a separate patch:
tools/configure.sh qemu-armv8a:knsh
This adds a qemu test target for testing kernel mode with arm64
priv->rxbuffer does not exist when CONFIG_ARM64_DCACHE_DISABLE=y so
references to it will create a build error -> flag / remove accesses
to it.
The format is always 64-bits
Need to instantiate the correct address environment when reading from
user stack, otherwise the result is very likely a crash
Unify the elf file format for the whole arm64 architecture
…tten

The page tables must be committed to system memory before we can proceed
enabling the MMU. ISB() is not enough to do this.
The TLS alignment requires more room in the stack, which means more
_initial_ heap is required to accomodate the stack.

Why 2x TLS_MAXSTACK ? No idea. This is a temporary fix, like the +1 page
extra above.
@pussuw pussuw force-pushed the arm64_kernelmode branch 2 times, most recently from 2a62ea2 to d22a8c5 Compare September 10, 2024 12:10
The expression "sub    x0,  x0, #8 * XCPTCONTEXT_GP_REGS" is void,
as the next instruction overwrites x0 anyway.
Make sure the user L1 page is updated to system memory when the kernel
mappings are copied.

Also, flush the I-cache when switching address environments.
The 12:0 bits in table descriptors are RES0 and AF is the 10th bit, so
it is not valid to set it in this case.

Fix this by moving AF to the common MMU_MT_NORMAL_FLAGS field
The vaddr field in TLBI means: Bits[55:12] of the virtual address to match.
This basically means the page offset of the virtual address, so the input
vaddr must be shifted to the page offset.

Reference TLBI VALE1IS register description from ARMv8-A reference manual.
The kernel L1 page table must be at least 1 page
This makes it more readable, no functional changes
…pages

Otherwise, user can run code from there
The register context is not needed, the original idea was to provide
the user stack pointer for signal handler delivery, but the user stack
can be obtained via sp_el0 so the context registers are not needed.

SP0 is not stored upon exception entry anyways, so this code is just
completely redundant and wrong.
The stack alignment requirement is 16-bytes, not 8-bytes.
Use them for critical section handling, removes a bit of copy&pasted
code behind CONFIG_ARM64_DECODEFIQ flag
…abled

Don't change the CPU state unexpectedly
There is a tiny possibility that when a process is started a trap is
taken which causes a context switch. This moves the kernel stack
unexpectedly and the task start logic no longer works.

Fix this by recording the initial context location, and use that to
trampoline into the user process with interrupts disabled. This ensures
the context stays intact AND the kernel stack is fully unwound before
the user process starts.
@pussuw pussuw changed the title [NOT FOR REVIEW]Arm64 kernelmode Arm64 kernelmode Sep 11, 2024
@pussuw
Copy link
Author

pussuw commented Sep 11, 2024

All patches besides 5b6c5fc are already in upstream

@pussuw pussuw merged commit de00c50 into master Sep 12, 2024
11 checks passed
@pussuw pussuw deleted the arm64_kernelmode branch September 12, 2024 07:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants