KVM: Beda KVM dengan QEMU
Qemu
QEmu adalah perangkat lunak lengkap dan mandiri. Kita menggunakannya untuk meniru mesin, dia sangat fleksibel dan portabel. Terutama bekerja dengan 'recompiler' khusus yang mengubah kode biner yang ditulis untuk prosesor diberikan ke processor lainnya (misalnya, kode MIPS untuk berjalan pada mac PPC, atau ARM dalam x86 PC).
Untuk meniru lebih dari sekedar prosesor, Qemu termasuk daftar panjang emulator periferal: disk, jaringan, VGA, PCI, USB, serial / port paralel, dll.
KQemu
Dalam kasus tertentu di mana kedua sumber dan target adalah arsitektur yang sama (seperti x86 pada x86), dia masih harus mengurai kode untuk menghapus 'previliged instructions' dan menggantinya dengan context switch. Untuk membuatnya seefisien mungkin pada x86 Linux, ada modul kernel yang disebut KQemu yang menangani ini.
Karena berbentuk modul kernel, KQemu mampu mengeksekusi sebagian besar code tanpa perubahan, menggantikan hanya tingkat yang paling rendah ring0-only instructions. Dalam hal ini, userspace Qemu masih mengalokasikan semua RAM untuk mesin ditiru, dan me-load code. Perbedaannya adalah bahwa daripada mengkompilasi ulang code, KQemu dipanggil untuk memindai / patch / eksekusi. Semua emulasi hardware periferal dilakukan di Qemu.
Ini jauh lebih cepat dari Qemu biasa karena sebagian besar code tidak berubah, tetapi masih harus mengubah ring0 code (sebagian besar code ini ada dalam kernel VM), sehingga kinerja masih tidak terlalu baik.
KVM
KVM is a couple of things: first it is a Linux kernel module—now included in mainline—that switches the processor into a new 'guest' state. The guest state has its own set of ring states, but privileged ring0 instructions fall back to the hypervisor code. Since it is a new processor mode of execution, the code doesn't have to be modified in any way.
Apart from the processor state switching, the kernel module also handles a few low-level parts of the emulation like the MMU registers (used to handle VM) and some parts of the PCI emulated hardware.
Second, KVM is a fork of the Qemu executable. Both teams work actively to keep differences at a minimum, and there are advances in reducing it. Eventually, the goal is that Qemu should work anywhere, and if a KVM kernel module is available, it could be automatically used. But for the foreseeable future, the Qemu team focuses on hardware emulation and portability, while KVM folks focus on the kernel module (sometimes moving small parts of the emulation there, if it improves performance), and interfacing with the rest of the userspace code.
The kvm-qemu executable works like normal Qemu: allocates RAM, loads the code, and instead of recompiling it, or calling KQemu, it spawns a thread (this is important). The thread calls the KVM kernel module to switch to guest mode and proceeds to execute the VM code. On a privileged instruction, it switches back to the KVM kernel module, which, if necessary, signals the Qemu thread to handle most of the hardware emulation.
One of the nice things of this architecture is that the guest code is emulated in a posix thread which you can manage with normal Linux tools. If you want a VM with 2 or 4 cores, kvm-qemu creates 2 or 4 threads, each of them calls the KVM kernel module to start executing. The concurrency—if you have enough real cores—or scheduling—if not—is managed by the normal Linux scheduler, keeping code small and surprises limited.