I also experimented with userland based approach (UserlandVM). The idea is to implement syscall translation fully on userland side and use special kernel interfaces only for mode switching. Currently it works for x86_64 host and riscv64 guest running with userland virtual machine and software emulation powered by TinyEMU or RVVM engine. x86_64 host and x86 guest need more work on syscall translation and hardware mode swithing.
4 Likes
How about a kernel driver that handles binaries not recognized by the normal runtime_loader and associates these binaries with a different syscall table? When a syscall is called control should be passed to this driver instead and syscall translation should happen there.
This way we can optionally install and uninstall x86 support or even ARM64 emulation support without using a different Haiku kernel version.
Why need a kernel driver? It is usually better to keep as much as possible in userspace for better stability and simplicity of development and testing. Kernel module seems have no speed benefits here. 32 bit x86 use commpage function call for syscalls, so it can be easily replaced with a call to syscall translation dispatcher.
4 Likes
We do need a kernel driver for virtualization though, if you are looking for kernel side work.
1 Like
I like kernel side work, but I don’t know how type-1 hypervisors (or hypervisors in general really) work so it might be hard to get started on porting virtualization implementations to Haiku.
Yes, it is not an easy task and I am not sure we have anyone who knows more.
https://gitweb.dragonflybsd.org/dragonfly.git/tree/HEAD:/sys/dev/virtual/nvmm
https://gitweb.dragonflybsd.org/dragonfly.git/tree/HEAD:/sys/dev/virtual
3 Likes
With the monster MilkV Pioneer Risc-V machine being announced [1], here’s a next gen idea:
If someone built a Haiku on Haiku hypervisor with riscv host support (risc-v virtualization support: Xen and the RISC-V Hypervisor Extension ), then the Haiku foundation could let certain trusted devs to have remote dev access to this machine via socksify for package testing and compiling, especially since Haiku is light on memory usage vs other OS. Or perhaps a native Risc-V hypervisor platform will emerge soon. Then we can leverage our synergies to create hyperconvergent buzzwords of scale 
Another idea is just multiple users running on the physical hardware, but we know that that is coming in R2.
[1] Milk-V
Also here’s more risc-v news, a Raspberry Pi form factor from MilkV: Milk-V Surprises with a Second RISC-V SBC — Physically Compatible with the Raspberry Pi 3 Model B - Hackster.io
1 Like
I made own brush engine for my graphics program - https://paintbrush-x1.com/ . I was thinking to port it to Haiku as new application as a drawing program for kids (different brushes) or integrate it into WonderBrush.
Are any of those two options suitable for GSOC ?
4 Likes