23 ms·

Hey, author of dynarmic here. > more context on why they're switching I started working on an AArch64 (ARMv8) frontend for dynarmic upon request from yuzu's d

Hey, author of dynarmic here. > more context on why they're switching I started working on an AArch64 (ARMv8) frontend for dynarmic upon request from yuzu's developers. At the time, they decided to switch over because dynarmic has better performance compared to unicorn. To be honest, I feel like unicorn has instrumentation as a primary goal. Dynarmic has different goals: (a) performance and (b) ease of integration into pre-existing/custom emulated memory systems. When I last looked at unicorn it didn't quite have a full ARMv8 implementation; yuzu maintains a fork of unicorn that follows upstream qemu more closely at https://github.com/yuzu-emu/unicorn https://github.com/yuzu-emu/unicorn. We use this version of unicorn to test dynarmic by fuzzing the emulators against each other to ensure accuracy of emulation. > how they gradually move over Dynarmic has "fallback" capability -- if an instruction isn't implemented, a user-provided callback is called so the library user can provide an implementation of the unimplemented instruction. yuzu uses unicorn as the fallback implementation. This was helpful for getting the system up and running in the early days. We're not quite at full ARMv8 support yet (we're at about 70% --- half-precision floating point support and ARM pointer authentication are the biggest unimplemented features), but the vast majority of guest applications in yuzu do not currently fallback to unicorn.

pm215 8y ago
QEMU hasn't got round to pointer-authentication yet either, so that's pretty good going. I like the "fuzz-test one implementation against another" approach. That's quite similar to how we test QEMU against real hardware (at least for straightforward userspace insns): https://git.linaro.org/people/peter.maydell/risu.git/tree/README https://git.linaro.org/people/peter.maydell/risu.git/tree/RE... (Upstream in QEMU we're talking/working on trying to improve our support for instrumentation. But definitely today we don't do anything much in that area.)
- MerryMage 8y ago
  > QEMU hasn't got round to pointer-authentication yet either, so that's pretty good going. Thanks very much! I do however note we're not trying for full system emulation for v8; we're primarily interested in userspace emulation since that's our primary usecase, so system instructions aren't necessary for us, which does reduce our workload! While we're on that topic, we make a few simplifying assumptions for performance reasons (e.g. no self-modifying code). Thinking about it, I feel like I should document these assumptions somewhere; I'll do that when I can. > That's quite similar to how we test QEMU against real hardware That's great! I love semi-automated testing. An emulator vs emulator fuzz test has some advantages: You can test more instructions than you are able to on hardware. For example, you can test arbitrary jump instructions and memory instructions (assuming the emulations have sufficient instrumentation to catch arbitrary memory reads/writes and jumps off into the ether). We fuzz against unicorn here: https://github.com/MerryMage/dynarmic/blob/master/tests/A64/fuzz_with_unicorn.cpp https://github.com/MerryMage/dynarmic/blob/master/tests/A64/.... This uses our instruction table (https://github.com/MerryMage/dynarmic/blob/master/src/frontend/A64/decoder/a64.inc https://github.com/MerryMage/dynarmic/blob/master/src/fronte...) to generate instructions.

pm215 8y ago

QEMU hasn't got round to pointer-authentication yet either, so that's pretty good going. I like the "fuzz-test one implementation against another" approach. That's quite similar to how we test QEMU against real hardware (at least for straightforward userspace insns): https://git.linaro.org/people/peter.maydell/risu.git/tree/README https://git.linaro.org/people/peter.maydell/risu.git/tree/RE... (Upstream in QEMU we're talking/working on trying to improve our support for instrumentation. But definitely today we don't do anything much in that area.)

MerryMage 8y ago
> QEMU hasn't got round to pointer-authentication yet either, so that's pretty good going. Thanks very much! I do however note we're not trying for full system emulation for v8; we're primarily interested in userspace emulation since that's our primary usecase, so system instructions aren't necessary for us, which does reduce our workload! While we're on that topic, we make a few simplifying assumptions for performance reasons (e.g. no self-modifying code). Thinking about it, I feel like I should document these assumptions somewhere; I'll do that when I can. > That's quite similar to how we test QEMU against real hardware That's great! I love semi-automated testing. An emulator vs emulator fuzz test has some advantages: You can test more instructions than you are able to on hardware. For example, you can test arbitrary jump instructions and memory instructions (assuming the emulations have sufficient instrumentation to catch arbitrary memory reads/writes and jumps off into the ether). We fuzz against unicorn here: https://github.com/MerryMage/dynarmic/blob/master/tests/A64/fuzz_with_unicorn.cpp https://github.com/MerryMage/dynarmic/blob/master/tests/A64/.... This uses our instruction table (https://github.com/MerryMage/dynarmic/blob/master/src/frontend/A64/decoder/a64.inc https://github.com/MerryMage/dynarmic/blob/master/src/fronte...) to generate instructions.