felix86 26.05
This month we worked on ptrace, fixed some bugs, and are patiently waiting for new hardware.
Working on ptrace
The wait for faster RISC-V hardware has us tackling long term emulation hurdles. One such task is emulating the ptrace syscall. This syscall, in short, is used for debugging. Programs like gdb, strace, and winedbg use it extensively. However, it is a powerful syscall that has many other uses. For example, the proot program uses ptrace to capture chroot, mount, and other syscalls and emulate them. Additionally, some Windows games are known to use equivalent Windows functionality to modify the debug registers, which Wine emulates via ptrace.
Unlike a lot of syscalls, the host ptrace syscall cannot be used to emulate the guest ptrace. This is for multiple reasons, the most important ones being differences in registers, distinction between host and guest syscalls and signals, the fact that we only want to stop the tracee at safepoints. The implementation we’re currently working on involves using the host ptrace to capture signals, but always continuing them with PTRACE_CONT on wait4 and similar syscalls if the tracee has not declared that it is in a “stop”. “Stops” in ptrace terms describe all the cases where a process (and threads) may stop execution to allow inspection by the tracer. By default, this happens on all signal deliveries except for SIGKILL. When the tracee needs to enter a “stop”, it will prepare some data for the tracer and raise a signal for itself. This time, instead of continuing, the tracer will return a WIFSTOPPED status in wait4, with the signal that caused the stop, and the guest program will know that it is now allowed to run commands that can only run when the tracee is stopped, such as PTRACE_PEEKDATA.
Ptrace is one of the hardest syscalls to properly emulate, so this change will take some time and is not yet complete. For more info, see the man page of ptrace.
Fixing fchownat
Somehow, fchownat didn’t go through our filesystem syscall emulation and ran the host version directly. This would cause “file not found” errors, with one example happening during guest package installation with apt. It is now fixed.
SpacemiT K3
As mentioned in a previous post, new RISC-V hardware will soon be available. This is exciting news for RISC-V projects like felix86, because the new hardware is RVA23 compatible and a lot faster than previously available hardware. Compared to the SoC we currently use, the SpacemiT K1, it seems to be around 3-4x faster in my felix86 benchmarks. It is possible that not all of that performance is translated to games directly, and some games will definitely require TSO emulation to be enabled which will hurt performance, since the X100 cores use out-of-order execution. However, this jump in performance will almost certainly allow for playing quite a few games at much greater framerates than in the K1, which is exciting.
SpacemiT will generously send us a physical board featuring this new SoC. More information, benchmarks, and hopefully videos of games running, will arrive after we receive the board and tinker with it. While unfortunately this board doesn’t feature a PCIe x16 or x8 slot, the M.2 M-Key slot may allow for connecting a GPU through a riser, similar to what we did with the Banana-Pi F3. Additionally, the K3 features a PowerVR GPU that has an open source Vulkan driver, which we need to look into making use of, if no discrete GPU is present.
Thanks for reading this post.
If you like this project, please give us a star on Github: https://github.com/OFFTKP/felix86