> For the complete documentation index, see [llms.txt](https://kmanu225.gitbook.io/cs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kmanu225.gitbook.io/cs/software-engineering/unix-linux-on-windows-choosing-the-right-environment/qemu-virtualization-and-hardware-emulation-on-windows.md).

# QEMU: Virtualization and Hardware Emulation on Windows

A traditional virtual machine lets you run a complete Linux system on Windows. [**QEMU**](https://www.qemu.org/download/) can do that too, but it has an additional capability: it can also emulate different hardware architectures.

That makes QEMU especially useful when the Linux system you need does not match the hardware of your Windows machine.

## Virtualization or emulation?

QEMU can work in two different ways.

If the guest and host use compatible CPU architectures, QEMU can use hardware-assisted virtualization. On Windows, QEMU supports the **Windows Hypervisor Platform (WHPX)** as an accelerator.

For example:

```
Windows x86_64
    |
    +-- QEMU + WHPX
           |
           +-- x86_64 Linux VM
```

In this case, QEMU behaves much like other virtualization solutions.

But QEMU can also emulate another CPU architecture using its **Tiny Code Generator (TCG)**. QEMU supports system emulation for architectures including x86, Arm, RISC-V, MIPS, PowerPC and others.

For example:

```
Windows x86_64
    |
    +-- QEMU
           |
           +-- emulated ARM64 machine
                    |
                    +-- ARM64 Linux
```

This is the feature that makes QEMU particularly interesting.

## When should you use QEMU?

QEMU is a good choice when:

> You need to reproduce a complete Linux machine, possibly with hardware different from your Windows host.

Typical examples include:

* [testing ARM Linux software from an x86 Windows workstation](/cs/software-engineering/cross-compilation.md);
* embedded Linux development;
* testing software for several CPU architectures;
* booting custom kernels or Linux images;
* reproducing virtual hardware;
* operating-system and low-level development.

QEMU can emulate not only CPUs but also many devices, buses, network adapters and other hardware components.

## QEMU vs VirtualBox or VMware

For a normal Linux desktop or server VM on the same CPU architecture, VirtualBox, VMware, or Hyper-V may provide a simpler user experience.

QEMU becomes especially valuable when **the hardware itself is part of what you need to reproduce**.

```
Need a normal x86 Linux VM?
    -> Hyper-V / VMware / VirtualBox / QEMU

Need to emulate another architecture?
    -> QEMU
```

The trade-off is performance: hardware-assisted virtualization can be close to native execution, while full CPU emulation requires QEMU to translate guest instructions and is therefore generally slower.

## Where QEMU fits

In our stack, QEMU sits in the virtualization/emulation path:

```
Linux guest
    |
virtual / emulated hardware
    |
QEMU
    |
Windows virtualization facilities / Windows kernel
    |
hardware
```

Unlike WSL, which focuses on providing an integrated Linux development environment, QEMU focuses on **creating a virtual machine and its hardware model**.

## Should you use QEMU?

Use QEMU when your requirement is:

> **"I need a complete Linux machine, and I may also need to reproduce another CPU architecture or specific virtual hardware."**

For ordinary Linux application development on Windows, WSL is usually simpler.

For ordinary same-architecture desktop VMs, Hyper-V, VMware, or VirtualBox may be easier to manage.

But for **cross-architecture, embedded, kernel, or low-level system development**, QEMU is one of the most flexible options.