Vtyjkyuk

According to official QEMU documentation:

When used as a virtualizer, QEMU achieves near native performance by executing the guest code directly on the host CPU.

My question is how is this behavior different from the programs we call hypervisors (e.g. VirtualBox, KVM etc); don't they also run the "guest code" on the "host CPU"? where else would they run it on?

Update:

If the image below (source) is correct, then it turns out that QEMU runs applications (and not entire OSs like hypervisors) but performs translations between different architecture types (e.g. a program written for ARM can run on x86)

Given the above, is the case that for one to run:

a) an entire operating system for a specific architecture (e.g ARM)

b) on a host with a different architecture (e.g amd64)

a co existence is needed of both

QEMU (to perform the cross-architecture mapping)

and

KVM (to act as hardware hypervisor)

is needed?

The paragraph you quote should be contrasted with the previous paragraph in the documentation:

When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your own PC). By using dynamic translation, it achieves very good performance.

The documentation is highlighting the difference between QEMU used as an emulator, which is slower because it involves translating binary code, versus QEMU used as a virtualiser.

Regarding the diagram, it’s incomplete. QEMU is very versatile and can be used on its own to emulate a full system, running a guest OS, or virtualise a full system, again running a guest OS, or emulate or virtualise a CPU within the host OS, running a guest application only. It can also be used to emulate devices for use with KVM.