Integrating QEMU in SystemC Virtual Platforms: why official library support would make it easier
QEMU is widely known and widely used open source machine emulator and virtualizer. It is fast, flexible and backed by a very large and active community. It is the obvious choice for many use cases, particularly when you need accurate instruction-level execution and broad architecture support. QEMU is very good at what it was designed for: executing software efficiently and accurately. As a result, more and more IP vendors deliver their subsystems for firmware development as customized QEMU-based models.
So far, so good. But what happens when these subsystems need to be integrated into a larger system? And what if early architectural exploration and firmware development require a simulation with timing? At this point, the question is not whether QEMU works, but how it fits into a timed, component-based virtual platform.
In practice, complex systems are often modeled in SystemC, where timing behavior and interactions between components can be described explicitly. However, SystemC is a modeling framework rather than a model library, and does not include processor or peripheral models out of the box. Besides other options like DBT-RISE, it therefore makes perfect sense to use the components available in QEMU.
Bear in mind, QEMU was never intended to be a timed component embedded in another simulation framework. Its execution model assumes that it is the simulator, not a participant in one. This leads to three fundamental challenges rooted in the original design goals for QEMU: a standalone execution model; functional (rather than timed) simulation; and the absence of a standardized, supported embedding API.
From the perspective of a virtual platform (VP), QEMU needs to behave like any other simulation component: it must be instantiable, it needs to participate in scheduling, interact through defined interfaces, and be synchronizable with simulated time.
This challenge is not new, and several solutions already exist. Commercial tools from large vendors integrate QEMU into their simulation environments, but these solutions are typically closed and not reusable outside their products. The QEMU-SC approach embeds SystemC modules into QEMU, which does not align with a SystemC-centric virtual platform architecture.
The most suitable solution for QEMU integration in a VP is QBox, developed by Greensocs and the Qualcomm Innovation Center (Quic on Github). QBox was explicitly designed to embed QEMU into SystemC in a clean and reusable way.
QBox builds on a layered architecture in which libqemu exposes QEMU as a library, libqemu-cxx provides a C++ abstraction, and libqbox integrates QEMU as a SystemC TLM-2.0 component.
Using this approach, QEMU can be instantiated like any other SystemC module and integrated into a larger virtual platform via standard TLM interfaces. Treating QEMU as a TLM component keeps the rest of the platform clean and modular.
Integrating QEMU into a SystemC virtual platform using libqemu and QBox is feasible and effective. The main issue we encountered is not technical, but organizational: libqemu is not part of the official QEMU releases.
In our project, we have to integrate a customer-specific QEMU fork with additional project-specific changes. Each QEMU update requires significant effort to realign the upstream QEMU base, the libqemu/QBox-related modifications, and the customer’s own extensions. Because libqemu is not part of the official QEMU repository, this integration effort repeats with every update.
Based on our experience, we believe the SystemC community would strongly benefit from official libqemu support in QEMU. A minimal, stable library interface could significantly reduce friction and make QEMU-based virtual platforms easier to build and maintain, building directly on the work already done by Greensocs and Qualcomm.
If you are dealing with similar integration challenges, get in touch: we would be happy to exchange our experience and to hear other viewpoints.