3 ms·
My rough view of emulating userspace and the syscall ABI is that the three main tricky parts are (1) signals (2) threads (3) mmap and generally handling the gue
by pm215 11y ago
My rough view of emulating userspace and the syscall ABI is that the three main tricky parts are (1) signals (2) threads (3) mmap and generally handling the guest address space; most of the rest is just a big pile of fiddly details. How does Usercorn do there currently? (Among other things there are some pretty tricky race conditions to avoid between signals and syscalls to make sure you return to the guest and don't acidentally block forever in a syscall.)
(I work on qemu, including its linux-user stuff...)
- lunixbochs 11y agoPosix mmap is generally working, because that's easily mapped to a core API in Unicorn. I exposed the qemu mem_map_ptr API for mapping files as well, but I haven't integrated it yet (I emulate file mmap for now by copying the file into guest memory). Signals are a pretty high priority, but are currently unimplemented. Usercorn has a trampoline mode that allows stopping the CPU, executing a section of code, and returning to the previous location when it's done. I can use this for signal dispatch. sigaction/signal syscalls will just register the address to call. fork/clone/threads in general are not yet implemented, but the groundwork is mostly there - I'm mainly worried about memory synchronization, and might need to add APIs to Unicorn for this. Unicorn supports running an arbitrary number of CPUs in parallel in the same process, so I'm actually planning on making both forked processes and threads run in the same host process, and do a sort of PID namespace/transparent layer. This will make stuff like emulating IPC or a process ptracing another process much easier to control, and I won't need an external process like wineserver to negotiate stuff the native system doesn't know how to do.