QEMU (Emulator and hardware virtualizer of a computer)

QEMU is a program that creates a virtual machine inside your computer, fully emulating the processor, memory and devices of another real or fictional architecture. It allows running operating systems built for one type of processor on completely different hardware without modifying the guest system code.

The main application area is server virtualization paired with KVM to achieve near-native performance when running isolated Linux and Windows environments. Embedded systems developers actively use QEMU for debugging microcontroller firmware and kernels without physical hardware. The tool is indispensable in cross-compilation and malware analysis, where emulation of ARM or MIPS on x86 architecture is required for safe dynamic analysis of binary files.

KVM (Turns the Linux kernel into a hypervisor)

Typical problems

The main technical difficulty lies in the dramatic performance drop in full software emulation mode, since translating each guest instruction into multiple host instructions creates enormous overhead. Working with graphical interfaces often causes delays and artifacts due to the lack of direct access to the physical graphics processor. Users regularly face the complexity of configuring the network stack, especially when setting up bridged connections and USB device passthrough, which require manual editing of access rights in the system.

How QEMU works

QEMU is based on two fundamentally different modes: full system emulation and user mode. In full emulation mode, QEMU recreates the entire computer in software, including the processor, chipset and peripheral buses. The key mechanism here is the dynamic binary translator Tiny Code Generator. It reads guest processor instructions in blocks, converts them into an architecture-independent intermediate representation, and then compiles them into machine code for the host processor. To speed up the work, QEMU caches the generated blocks, avoiding re-translation of frequently executed code sections. When processing input-output operations, the emulator intercepts port and memory accesses, mapping them to the corresponding virtual devices.

Radical acceleration is achieved when using hardware virtualization through KVM or Hypervisor.framework. In this case, QEMU stops translating code manually: guest instructions are directly executed by the physical processor in a special protection ring. The Linux kernel KVM module switches the processor to guest mode and handles exits from it due to interrupt signals or exception situations. Meanwhile, QEMU manages only the emulation of external devices: network cards, disk controllers and graphics adapters. To access disk images, a multi-level system of block drivers is used, capable of working with raw and qcow2 formats with support for copy-on-write, state snapshots and compression. Network traffic is either isolated in a private virtual network with its own DHCP server, or bridged into the physical network through TAP interfaces created at the operating system kernel level.

QEMU functionality

  1. Guest processor emulation via Tiny Code Generator. QEMU uses its own dynamic translator TCG, converting target architecture instructions into an intermediate representation, and then into host code. This allows achieving acceptable execution speed without hardware virtualization on completely incompatible architectures.
  2. Hardware virtualization via KVM. The Linux kernel module (KVM) turns QEMU into a lightweight orchestrator, passing guest instructions directly to the physical processor via Intel VT-x or AMD-V extensions. QEMU is responsible for emulating input-output devices and setting up the environment.
  3. Intel VT-x (Hardware Virtualization of the CPU)AMD-V (Hardware virtualization using the processor)
  4. Hypervisor Framework mode support. On macOS, QEMU integrates with Hypervisor.framework, using system calls to create virtual machines on Apple Silicon and Intel chips. This provides near-native performance without the need to install third-party kernel extensions.
  5. Acceleration via Windows Hypervisor Platform. QEMU can work in tandem with WHPX — a Windows hypervisor component. This mechanism leverages low-level OS capabilities to run unmodified guest systems with minimal overhead at the user mode level.
  6. Storage device emulation. The block device emulation subsystem provides a wide range of controllers: from classic IDE and AHCI (SATA) to modern NVMe and paravirtual virtio-blk. The snapshot mechanism allows saving the complete disk state and restoring it for repeated tests.
  7. Network stack with software hub. QEMU implements the SLiRP virtual switch, operating entirely in user space without administrator privileges. The guest operating system accesses the network via NAT, and TCP and UDP protocols are correctly translated through host system sockets.
  8. USB device interception and passthrough. QEMU is capable of redirecting physical devices connected to the host bus directly into the guest environment. The usb-host driver is used, capturing the device descriptor at the operating system level, ensuring transparent operation of flash drives, tokens and security keys.
  9. Graphics output via VirtIO-GPU. The paravirtual virtio-gpu driver is used to accelerate the graphical interface. This adapter implements the Virgil3D protocol, which serializes OpenGL or Vulkan commands in the guest OS and passes them for rendering to the host video card without raster buffer emulation.
  10. VirtIO-GPU (Hardware-accelerated virtual GPU)
  11. Video adapter passthrough (GPU Passthrough). VFIO technology allows exclusively assigning a physical graphics processor to a virtual machine. QEMU unbinds the host driver from the device, activates IOMMU for DMA isolation and provides the guest with direct control over the hardware.
  12. IOMMU (Isolation of direct memory access addresses)VFIO (Direct device Input-Output virtualization)
  13. Console output without a monitor. For headless modes, QEMU emulates a UART 16550A serial port. The data stream can be directed to stdio, pty or a TCP socket, providing remote administration of guest systems without a graphical interface through standard terminal clients.
  14. VM state migration system. The live migration function copies the contents of RAM and processor register states to another host. The process is performed iteratively in the background with minimal downtime, using TCP or Unix sockets for transmission.
  15. File image generation via qemu-img utility. The tool manipulates virtual disks of QCOW2, VMDK, VHDX and other formats. It supports operations for creating sparse volumes, converting between formats, integrity checking and capacity expansion without mounting the guest file system.
  16. QCOW2 snapshot mechanism. The Copy-On-Write file structure allows storing only changed sectors on top of a base image. Creating a snapshot captures the VM state without copying all data, and rollback instantly discards the written diff-blocks to the reference save point.
  17. Dynamic memory allocation via balloon. The virtio-balloon device allows the hypervisor to reclaim unused memory pages from the guest OS or return them back. QEMU interacts with a special driver inside the guest, changing the visible RAM size without rebooting the machine.
  18. Virtio-balloon (Redistribution of unused guest system memory)
  19. QEMU Guest Agent integration. The qemu-ga daemon installed inside the VM establishes a communication channel via virtio-serial. It allows the hypervisor to execute commands inside the guest: proper file system freezing (quiesce), password changes and network metric retrieval.
  20. QEMU Guest Agent (Host-Guest communication service channel)
  21. Cryptographic protection operation. QEMU supports built-in on-the-fly disk image encryption. The LUKS format is integrated into the block layer, allowing guest data to be stored on the host disk in encrypted form, requesting a passphrase when starting the virtual machine.
  22. Device tree generation. When running on ARM and RISC-V platforms, QEMU dynamically creates a Device Tree Blob. This data structure describes connected peripheral devices and memory map, passing it to the bootloader or guest OS kernel for correct hardware detection.
  23. SPICE session protocol. QEMU acts as a server for the SPICE remote desktop protocol, specifically designed for virtualization. It separates video, audio and USB control streams into different channels, optimizing graphics responsiveness and bidirectional audio traffic.
  24. Tracing and debugging via GDB Stub. The built-in GDB protocol server allows an external debugger to connect to a running VM. The developer can inspect memory, registers and step through code both in the early boot stages and inside the running OS kernel.
  25. Fault injection for testing. The write-blocking and I/O fault generation subsystem in the block layer allows simulating hard disk failures. This makes it possible to test the resilience of file systems and applications to data loss without physically disconnecting the media.

Comparisons

  • QEMU vs KVM. QEMU is an emulator with full software processor virtualization, capable of reproducing architectures different from the host, whereas KVM is a hypervisor at the Linux kernel level. In the QEMU-KVM combination, maximum performance is achieved: KVM uses Intel VT-x/AMD-V hardware virtualization extensions for direct code execution, and QEMU emulates only input-output devices.
  • QEMU vs VirtualBox. VirtualBox is oriented towards desktop virtualization with a graphical interface and seamless cursor integration, while QEMU offers unparalleled flexibility via CLI and automation scripts. QEMU supports emulation of many non-x86 architectures (ARM, RISC-V) without recompiling the guest OS, whereas VirtualBox is strictly limited to cross-platform capability only at the host system level.
  • QEMU vs Xen. Xen uses a microkernel model with a privileged control domain (Dom0) and paravirtualization, requiring guest kernel modification to achieve near-native speed. QEMU in emulation mode is completely free from the need to modify the guest OS. At the same time, Xen often uses QEMU as a backend for emulating network and block devices in HVM mode.
  • Dom0 (Xen Virtual Machine management)HVM (Hardware isolation and virtualization acceleration)
  • QEMU vs VMware Workstation. VMware offers a closed commercial stack with advanced 3D graphics acceleration and DirectX support, providing superior Windows desktop performance. QEMU, on the other hand, is an open-source solution virtualizing GPU via VirtIO-GPU or VFIO passthrough. QEMU’s architectural emulation is indispensable for embedded development and debugging code for different processor architectures without physical hardware.
  • QEMU vs Hyper-V. Hyper-V is deeply integrated into Windows OS as a server role, using synthetic drivers to minimize I/O overhead. QEMU functions as a user-space process in Linux, relying on VirtIO drivers. The key difference in usage scenarios: Hyper-V serves enterprise Windows Server clusters, while QEMU is indispensable for heterogeneous computing environments and malware behavior research through deterministic instruction emulation.

OS and driver support

KVM provides support for a wide range of guest operating systems (Linux, Windows) through the use of paravirtualized Virtio drivers, which are implemented via a common framework with a frontend part in the guest OS and a backend part in the hypervisor (usually QEMU), significantly improving the performance of network and block I/O devices.

Security

Security is implemented through a multi-layered approach: since virtual machines are ordinary Linux processes, KVM uses the standard kernel security model and SELinux, and the sVirt project builds on top to apply mandatory access control (MAC) and isolation, assigning unique security labels to each guest process and its resources to prevent a compromised VM from accessing the host or other machines.

Logging

Logging in the KVM environment is implemented through the integration of the libvirtd daemon with the Linux audit subsystem (auditd), which by default records all important VM lifecycle events (start, stop), configuration changes and security context bindings to the /var/log/audit/audit.log file, allowing administrators to maintain a canonical operations journal.

Limitations

The main limitations of KVM manifest in scenarios with strict real-time requirements due to unpredictable delays introduced by the hypervisor and resource sharing; however, techniques such as vCPU pinning, core isolation (isolcpus), NUMA topology binding and direct device assignment via PCI Passthrough are used to overcome these and reduce virtualization overhead.

History and development

KVM was created by Qumranet in 2006, integrated into the mainline Linux kernel 2.6.20 in early 2007, and after Qumranet’s acquisition by Red Hat in 2008, its active development and complete replacement of Xen in enterprise distributions began, facilitated by the creation of the Open Virtualization Alliance in 2011 with the participation of IBM and Intel.

Latest publications