Deterministic Replay of QEMU Emulation
QEMU version 9.0.94 introduces a record/replay feature for deterministic virtual machine execution, supporting multiple hardware platforms, snapshotting, automatic data recording, and reverse debugging capabilities using GDB commands.
Read original articleQEMU version 9.0.94 includes a record/replay feature that allows for deterministic replay of virtual machine execution. This functionality records non-deterministic events, such as keyboard input and network packets, while simulating deterministic events like memory reads. The recorded execution log can be replayed multiple times on different machines, supporting various hardware platforms including x86, ARM, and PowerPC. To utilize this feature, users must run QEMU in icount mode, which enables deterministic execution. The command lines for recording and replaying differ only in the option for the rr parameter. The record/replay system also supports snapshotting, allowing users to create VM snapshots during replay for state recovery. Network interactions are managed through a replay filter, and audio and serial port data are recorded automatically. Additionally, reverse debugging capabilities are available, enabling users to step back through execution using GDB commands. This feature requires at least one snapshot to be created during the recording process. Overall, the record/replay functionality enhances debugging and testing capabilities within QEMU.
- QEMU's record/replay feature allows deterministic replay of VM execution.
- It supports various hardware platforms and requires icount mode for operation.
- Users can create snapshots during replay for state recovery.
- Network interactions and audio/serial data are automatically recorded.
- Reverse debugging is enabled through GDB commands, requiring snapshots.
Related
Re-visiting VM/386 (2023)
The author shares experiences with VM/386, an emulation software from 1988. Running on 86box, it enables multitasking on an 80386 processor with graphical PC programs, despite limitations hindering broader success.
rr – record and replay debugger for C/C++
RR is a C/C++ debugging tool for Linux, enhancing gdb by enabling deterministic recording and replay of failures, supporting various applications like Firefox, with low overhead and a chaos mode.
rrweb – record and replay debugger for the web
rrweb.io is an open-source web session replay library enabling remote replay of website interactions. It supports user analysis, bug reproduction, demos, and collaboration. Users can sponsor and receive recognition. Trusted by companies with interactive demos available.
Haiku OS [GSoC 2024] Hardware Virtualization: Final Report
The GSoC 2024 project enhanced the Haiku operating system by integrating NVMM hypervisor support, achieving key milestones but facing unresolved issues with SVM backend, OS compatibility, and performance discrepancies.
KLEE Symbolic Execution Engine
KLEE is a symbolic virtual machine based on LLVM, enabling symbolic execution of bitcode with a POSIX/Linux emulation layer, allowing input replay on native and emulated environments for software testing.
https://github.com/jbreu/jos?tab=readme-ov-file#reverse-debu...
I can think of using this for testing, and as a vehicle to change a programming paradigm of existing/legacy software (run a thing, and roll it back aggressively from outside of a vm)
While it might seem like a small feature, it opens a huge door. It's similar to what reproducible build infrastructure has done for finding bugs, attestation that binary matches source, immutability, etc.
Can imagine this is useful for finding bugs in hardware designs too.
Say capturing a Qt application as it corrupts its internal state during startup, in order to work out what's corrupting its internal state?
1 . Would something like this replace packer for creating machine images?
2. Curious how quickly the replay log grows and how it compares to a CoW snapshot.
3. Will be interesting what the log looks like and what doors could open up creating or generating it by other means.
Does this sound right? I’m trying to figure out where uncontrollable randomness would come in during a compile phase, and coming up blank.
http://stackframe.blogspot.com/2007/10/configuring-applicati...
http://www.replaydebugging.com/2008/08/vmware-workstation-65...
Related
Re-visiting VM/386 (2023)
The author shares experiences with VM/386, an emulation software from 1988. Running on 86box, it enables multitasking on an 80386 processor with graphical PC programs, despite limitations hindering broader success.
rr – record and replay debugger for C/C++
RR is a C/C++ debugging tool for Linux, enhancing gdb by enabling deterministic recording and replay of failures, supporting various applications like Firefox, with low overhead and a chaos mode.
rrweb – record and replay debugger for the web
rrweb.io is an open-source web session replay library enabling remote replay of website interactions. It supports user analysis, bug reproduction, demos, and collaboration. Users can sponsor and receive recognition. Trusted by companies with interactive demos available.
Haiku OS [GSoC 2024] Hardware Virtualization: Final Report
The GSoC 2024 project enhanced the Haiku operating system by integrating NVMM hypervisor support, achieving key milestones but facing unresolved issues with SVM backend, OS compatibility, and performance discrepancies.
KLEE Symbolic Execution Engine
KLEE is a symbolic virtual machine based on LLVM, enabling symbolic execution of bitcode with a POSIX/Linux emulation layer, allowing input replay on native and emulated environments for software testing.