Trying to Explain QEMU in Simple Terms (Part 1):QEMU’s Usage Scenarios
Introduction
QEMU is, in simple terms, an open-source CPU emulator. The name stands for Quick Emulator, and it’s commonly pronounced as “Q-Emu” or “Q-E-M-U,” though some may refer to it as “Kemu.”
Our company also offers modeling services related to QEMU. While QEMU is a highly useful tool, many might wonder, “What exactly is QEMU?”
For more information about our QEMU modeling services, please refer to the following URL:
When we first encountered QEMU around 2010, we were able to run it by referring to various online articles, but we didn’t quite understand it. One reason for QEMU’s complexity is the variety of its use cases—it has many different usages.
Additionally, it might be unclear who should use QEMU. For instance, both embedded software engineers and hardware engineers involved in semiconductor design, such as System on a Chip (SoC) development, might use it.
Therefore, in this series, we aim to explain the workings of QEMU in multiple parts, making it as understandable as possible for beginners. The content might be insufficient for intermediate and advanced users. Note that we will not cover specific installation methods or usage instructions for QEMU.
In Part 1 of this series, we will explain one of the many use cases of QEMU and aim to provide a general understanding of what QEMU is.
What is QEMU?
QEMU is an open-source CPU emulator and system emulator. It allows you to run software designed for different CPU architectures and create virtualized hardware environments. That being said, just reading this definition might not be enough to fully understand what QEMU actually is.
You will likely get a better sense of it by reading the following section, “QEMU’s Usage Scenarios”.
We used the term “emulator”, which might sound technical, but you could also call it a “simulator”. The difference between an emulator and a simulator is a complex topic, so we will not go into detail here. For the sake of this series, we will use “emulator” and “simulator” interchangeably. However, for semiconductor designers (LSI designers), they might object and say,”No, an emulator and a simulator are completely different things!” That may be true in certain contexts, but for understanding QEMU, we don’t think this distinction is particularly important.
QEMU is an advanced piece of software written in C language. Its source code is publicly available. QEMU is quite complex, and just understanding how to use it can be challenging.
QEMU is open-source, and its licensing details are as follows:
- The overall QEMU project follows GNU GPL version 2.
- Individual source files include a mix of GPL, LGPL, and other licenses.
We won’t go into too much detail here, but if you modify QEMU and distribute it externally, you must also make your source code publicly available.
QEMU’s Usage Scenarios
One of the reasons that makes understanding QEMU difficult is that it has a wide range of use cases. First, here are some examples of QEMU’s usage scenarios:
- Firmware testing in an embedded development environment
- Software porting between different architectures
- Building virtual machines to run different operating systems
Here are some more specific examples:
- 1. Developing software for ARM CPUs without having a physical device
- When an OS is available for the ARM CPU. Example: Linux.
- When no OS is available for the ARM CPU (so-called bare-metal development).
- When the physical device has been developed, but is not currently available (e.g., remote work).
- When the physical device has been developed, but there are not enough units available.
- When you want to induce hardware failures that are difficult to reproduce on the actual device.
- When the physical device is yet to be developed (e.g., planning to develop an SoC).
- 2. Running Linux on Windows
- This can also be achieved using VMware or VirtualBox.
Additionally, although it is not covered in Part 1, when running Linux on QEMU, the following terms will appear, which may be quite confusing for beginners learning QEMU:
- System Mode (System Emulation)
- User Mode (User Mode Emulation)
- KVM
In addition, terms such as “hypervisor” may also appear, making it even more difficult to understand. Some people may find themselves completely lost, unsure of what everything means.
Also, in the earlier examples of usage scenarios, we used ARM CPUs as an example, but the same applies to other CPUs supported by QEMU, such as RISC-V.
From here on, we will take one specific usage scenario of QEMU and explore it in depth.
Usage Scenario 1: Physical ARM CPU Device Completed, No Access to the Physical Device, No OS
We were unsure which usage scenario to start with. However, we chose this first scenario because understanding how QEMU works in this case will make it easier to grasp other scenarios as well.
In Part 1 of this series, we will only provide an overview of this usage scenario. The detailed explanation of how QEMU works will be covered in Part 2 and beyond.
This QEMU usage scenario assumes the following situation:
・A physical device equipped with an ARM CPU has already been completed.
・Due to various circumstances, the physical device is not accessible, but you still need to develop embedded software for it.
More specifically, this could apply to a case where you are developing embedded software using an ARM-based physical device at your office and wish to continue your work at home, but you do not have access to the physical device at home.
When a physical device is available
First, Figure 1 illustrates a general image of embedded software development using the physical device.

In Figure 1, the source code for a C program is created on an x86-based PC. After writing the source code, the same PC uses the ARM-specific gcc (C compiler) to cross-compile the C source file, generating an ARM-compatible binary (executable). The ARM binary is then transferred to the physical device, where the program is executed on the device.
Although the term cross-compilation might sound complex, the basic concept is the same as regular compilation. The difference is that if you use a standard gcc (for x86) instead of the ARM-specific gcc, it will generate an x86 binary (executable). If this x86 binary is sent to an ARM-based device and executed, the program will not run correctly. This is because the x86 binary contains x86-specific machine code, which the ARM CPU cannot process.
A cross-compiler is a compiler that generates binary files (executables) for a platform (in this case, ARM CPU) other than the one it is running on (in this case, x86).
Now, you might wonder, “Why not just compile directly on the physical device instead of dealing with cross-compilation?” While that’s a valid point, physical devices often have limited resources and may not be able to support the setup of a full compilation environment. Additionally, if the physical device isn’t available yet, compiling directly on it is simply not possible.
When the Physical Device is Not Available
When the physical device is not available, QEMU is used on a PC to simulate the device. Software that mimics the physical device in this way is called “virtual hardware,” “virtual machine,” or “virtual platform.”
The following diagram shows how QEMU simulates the physical device.

In Figure 2, generating the ARM CPU binary (executable) is the same as in the case where a physical device is available. In the case with a physical device, the ARM CPU binary (executable) was transferred to the device. However, when the physical device is not available, the ARM CPU binary (executable) is sent to QEMU instead.
When we say “sending to QEMU,” it simply means passing the binary to QEMU as a -kernel option argument in the QEMU execution command. In Figure 2, QEMU is executed as shown below.
%qemu-system-arm -M lm3s811evb -kernel hello.elf
In the command above, the -M option is followed by the string lm3s811evb, which refers to the model of an evaluation board with an ARM Cortex-M3 CPU. The -M option’s “M” stands for “Machine.”
When this command is executed, QEMU runs on the PC and displays “Hello World!” (as shown in the bottom right of Figure 2). In general, from the perspective of a virtual machine, the CPU physically installed on the PC is referred to as the “host CPU.” On the other hand, the CPU being emulated (simulated) inside the virtual machine (in QEMU) is referred to as the “guest CPU.” In this case, from QEMU’s perspective, the x86 CPU is the host CPU, and the ARM CPU is the guest CPU. To summarize, the host refers to the actual physical machine running QEMU, while the guest refers to the virtual machine or software environment emulated by QEMU.
One question arises here: Who creates the QEMU that simulates the physical device? For example, if the physical device is equipped with a custom SoC, the open-source QEMU will not be able to simulate the SoC. In this case, it is necessary for the company to develop a QEMU C model for the SoC. However, models for various CPUs, general-purpose peripherals (such as UARTs), and commercially available evaluation boards are already included in QEMU as libraries. If the required peripheral is not available as a library, it will be necessary to develop a custom QEMU C model for it.
Additionally, the C models for commercially available evaluation boards that are pre-registered in QEMU do not model all the peripherals installed on the physical device. For example, UARTs and timers on commercial evaluation boards are often modeled in QEMU, but some specialized peripherals may not be supported. Even without providing C models for all peripherals, it is still possible to develop embedded software for a large portion of the system.
Next Time
In this article (Part 1), We explained one of the usage scenarios of QEMU.
In the next time (Part 2), we will explain how QEMU emulates ARM CPU instructions on an x86 machine.