[Paper] NQC2: A Non-Intrusive QEMU Code Coverage Plugin
Source: arXiv - 2601.02238v1
Overview
The paper introduces NQC2, a non‑intrusive plugin for the QEMU emulator that harvests code‑coverage data from embedded (bare‑metal) applications without any source‑level instrumentation. By pulling coverage metrics directly from the emulated CPU state and writing them to the host, NQC2 sidesteps the need for an operating system or filesystem on the target, making coverage analysis feasible for low‑level firmware and IoT code.
Key Contributions
- Non‑intrusive coverage extraction: Captures line‑ and branch‑level coverage from QEMU at runtime without modifying the target binary.
- Host‑side storage: Automatically writes coverage reports to the host filesystem, eliminating the need for target‑side storage or communication channels.
- Compatibility layer: Works with vanilla QEMU as well as custom‑patched builds, preserving existing emulation workflows.
- Performance gains: Demonstrates up to 8.5× faster execution compared with Xilinx’s instrument‑and‑dump approach for similar workloads.
- Open‑source implementation: Provides a reusable plugin that can be integrated into CI pipelines for embedded firmware testing.
Methodology
- Instrumentation‑free design – NQC2 hooks into QEMU’s internal execution engine (specifically the translation block handling) to monitor which basic blocks are executed.
- Runtime data collection – As the emulated program runs, the plugin records block identifiers in a compact bitmap kept in host memory.
- Periodic flushing – At user‑defined intervals or on emulator shutdown, the bitmap is serialized into a standard coverage format (e.g., gcov/LCOV) and saved on the host machine.
- Evaluation setup – The authors benchmarked NQC2 against Xilinx’s “instrument‑and‑dump” method using several open‑source bare‑metal applications (e.g., FreeRTOS demos, Zephyr samples). Metrics collected included execution time overhead, memory consumption, and coverage completeness.
Results & Findings
| Metric | NQC2 | Xilinx Instrumentation |
|---|---|---|
| Runtime overhead | ≤ 2 % (average) | 10–17 % |
| Speedup | Up to 8.5× faster overall test runs | – |
| Coverage completeness | 100 % of executed blocks reported (identical to instrumented baseline) | 100 % |
| Host memory impact | Negligible (bitmap size < 1 MB for typical firmware) | Comparable |
| Ease of integration | Drop‑in QEMU plugin, no source changes | Requires recompilation with coverage macros |
The findings confirm that extracting coverage directly from the emulator is both accurate and significantly more efficient than traditional source‑level instrumentation for bare‑metal targets.
Practical Implications
- CI/CD for firmware – Teams can embed NQC2 into automated test pipelines, obtaining fast coverage feedback without maintaining separate instrumented builds.
- Rapid prototyping – Developers iterating on low‑level drivers can see coverage instantly, shortening the debug loop for edge‑case code paths.
- Resource‑constrained devices – Since no extra code runs on the target, NQC2 is ideal for microcontrollers lacking flash or RAM for instrumentation payloads.
- Cross‑tool compatibility – The generated coverage files can be fed into existing analysis tools (lcov, gcovr, SonarQube), preserving existing reporting dashboards.
- Vendor‑agnostic testing – Works with any QEMU‑supported architecture (ARM Cortex‑M, RISC‑V, etc.), enabling a unified coverage strategy across heterogeneous product lines.
Limitations & Future Work
- Emulation‑only – NQC2 relies on QEMU; coverage data from hardware runs still requires traditional instrumentation or external tracing hardware.
- Granularity bound to QEMU’s translation blocks – While sufficient for most line‑level metrics, ultra‑fine‑grained (e.g., per‑instruction) coverage would need deeper hooks.
- Potential divergence between emulated and real hardware timing may hide race‑condition bugs that only appear on silicon.
- Future directions suggested by the authors include: extending the plugin to capture performance counters alongside coverage, integrating with hardware‑in‑the‑loop (HIL) setups to merge emulated and real‑world data, and adding support for dynamic binary translation frameworks beyond QEMU.
Authors
- Nils Bosbach
- Alwalid Salama
- Lukas Jünger
- Mark Burton
- Niko Zurstraßen
- Rebecca Pelke
- Rainer Leupers
Paper Information
- arXiv ID: 2601.02238v1
- Categories: cs.SE
- Published: January 5, 2026
- PDF: Download PDF