mirror of
https://github.com/FEX-Emu/FEX.git
synced 2026-10-24 18:00:44 +02:00
Ryan Houdek
f9b352a093
When a fork occurs FEX needs to be incredibly careful as any thread
(that isn't forking) that holds a lock will vanish when the fork occurs.
At this point if the newly forked process tries to use these mutexes
then the process hangs indefinitely.
The three major mutexes that need to be held during a fork:
- Code Invalidation mutex
- This is the highest priority and causes us to hang frequently.
- This is highly likely to occur when one thread is loading shared
libraries and another thread is forking.
- Happens frequently with Wine and steam.
- VMA tracking mutex
- This one happens when one thread is allocating memory while a fork
occurs.
- This closely relates to the code invalidation mutex, just happens at
the syscall layer instead of the FEXCore layer.
- Happens as frequently as the code invalidation mutex.
- Allocation mutex
- This mutex is used for FEX's 64-bit Allocator, this happens when FEX
is allocating memory on one thread and a fork occurs.
- Fairly infrequent because jemalloc doesn't allocate VMA regions that
often.
While this likely doesn't hit all of the FEX mutexes, this hits the ones
that are burning fires and are happening frequently.
- FEXCore: Adds forkable mutex/locks
Necessary since we have a few locations in FEX that need to be locked
before and after a fork.
When a fork occurs the locks must be locked prior to the fork. Then
afterwards they either need to unlock or be set to default
initialization state.
- Parent
- Does an unlock
- Child
- Sets the lock to default initialization state
- This is because it pthreads does TID based ownership checking on
unique locks and refcount based waiting for shared locks.
- No way to "unlock" after fork in this case other than default
initializing.
FEXCore - Fast x86 Core emulation library
This is the core emulation library that is used for the FEX emulator project. This project aims to provide a fast and functional x86-64 emulation library that can meet and surpass other x86-64 emulation libraries.
Goals
- Be as fast as possible, beating and exceeding current options for x86-64 emulation
- 25% - 50% lower performance than native code would be desired target
- Use an IR to efficiently translate x86-64 to our host architecture
- Support a tiered recompiler to allow for fast runtime performance
- Support offline compilation and offline tooling for inspection and performance analysis
- Support threaded emulation. Including emulating x86-64's strong memory model on weak memory model architectures
- Support a significant portion of the x86-64 instruction space.
- Including MMX, SSE, SSE2, SSE3, SSSE3, and SSE4*
- Support fallback routines for uncommonly used x86-64 instructions
- Including x87 and 3DNow!
- Only support userspace emulation.
- All x86-64 instructions run as if they are under CPL-3(userland) security layer
- Minimal Linux Syscall emulation for testing purposes
- Portable library implementation in order to support easy integration in to applications
Target Host Architecture
The target host architecture for this library is AArch64. Specifically the ARMv8.1 version or newer. The CPU IR is designed with AArch64 in mind but should allow for other architectures as well. x86-64 host support is available for ease of development, but is not a priority.
Not desired
- Kernel space emulation
- CPL0-2 emulation
- Real Mode, Protected Mode, Virtual-8086 Mode, System Management Mode
- IRQs
- SVM
- "Cycle Accurate" emulation