KVM: Beda KVM dengan QEMU - Revision history

Unknown user: /* KVM */

2023-04-27T02:35:34Z

KVM

← Older revision		Revision as of 02:35, 27 April 2023
Line 15:		Line 15:
	==KVM==		==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~~.		KVM ada beberapa hal: pertama adalah modul kernel Linux—sekarang termasuk dalam mainline—yang mengalihkan prosesor ke status 'guest' baru. Status guest memiliki rangkaian status ring sendiri, tetapi instruksi ring0 yang diistimewakan kembali ke kode hypervisor. Karena ini adalah mode eksekusi prosesor baru, kode tidak perlu dimodifikasi dengan cara apa pun.

	~~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~~.		Terlepas dari peralihan status prosesor, modul kernel juga menangani beberapa bagian tingkat rendah dari emulasi seperti register MMU (digunakan untuk menangani VM) dan beberapa bagian perangkat keras yang diemulasi PCI.

	~~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.~~		Kedua, KVM adalah fork dari eksekusi Qemu. Kedua tim bekerja secara aktif untuk meminimalkan perbedaan, dan ada kemajuan dalam menguranginya. Pada akhirnya, tujuannya adalah agar Qemu dapat bekerja di mana saja, dan jika modul kernel KVM tersedia, modul tersebut dapat digunakan secara otomatis. Tetapi untuk masa mendatang, tim Qemu berfokus pada emulasi dan portabilitas perangkat keras, sementara orang-orang KVM fokus pada modul kernel (terkadang memindahkan sebagian kecil emulasi ke sana, jika itu meningkatkan kinerja), dan berinteraksi dengan kode ruang pengguna lainnya.

	~~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~~.

			Eksekusi kvm-qemu berfungsi seperti Qemu normal: mengalokasikan RAM, memuat kode, dan alih-alih mengkompilasi ulang, atau memanggil KQemu, itu memunculkan utas (ini penting). Utas memanggil modul kernel KVM untuk beralih ke mode tamu dan mulai mengeksekusi kode VM. Pada instruksi istimewa, ia beralih kembali ke modul kernel KVM, yang, jika perlu, memberi sinyal pada utas Qemu untuk menangani sebagian besar emulasi perangkat keras.

			Salah satu hal yang menyenangkan dari arsitektur ini adalah kode guest diemulasi dalam posix thread yang dapat Anda kelola dengan tool Linux biasa. Jika Anda menginginkan VM dengan 2 atau 4 core, kvm-qemu membuat 2 atau 4 thread, masing-masing memanggil modul kernel KVM untuk mulai mengeksekusi. Konkurensi—jika Anda memiliki cukup real core -or scheduling—if not—dikelola oleh scheduler Linux biasa, menjaga agar kode tetap kecil dan surprise terbatas.

	==Referensi==		==Referensi==

	* http://serverfault.com/questions/208693/difference-between-kvm-and-qemu		* http://serverfault.com/questions/208693/difference-between-kvm-and-qemu

Onnowpurbo: /* KQemu */

2015-02-14T23:50:29Z

KQemu

← Older revision		Revision as of 23:50, 14 February 2015
Line 9:		Line 9:
	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.		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 ~~perifer~~ dilakukan di Qemu.		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.		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.

Onnowpurbo at 23:13, 14 February 2015

2015-02-14T23:13:56Z

← Older revision		Revision as of 23:13, 14 February 2015
Line 1:		Line 1:
	Qemu:		==Qemu==

	QEmu ~~is a complete and standalone software of its own~~. ~~You use it to emulate machines~~, ~~it is very flexible and portable~~. ~~Mainly it works by a special~~ 'recompiler' ~~that transforms binary code written for a given~~ processor ~~into another one~~ (~~say~~, ~~to run~~ MIPS ~~code on a~~ PPC ~~mac~~, or ARM ~~in an~~ x86 PC).		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).

	~~To emulate more than just the processor~~, Qemu ~~includes a long list of peripheral emulators~~: disk, ~~network~~, VGA, PCI, USB, serial/~~parallel ports~~, ~~etc~~.		Untuk meniru lebih dari sekedar prosesor, Qemu termasuk daftar panjang emulator periferal: disk, jaringan, VGA, PCI, USB, serial / port paralel, dll.

	KQemu:		==KQemu==

	~~In the specific case where both source and~~ target ~~are the same architecture~~ (~~like the common case of~~ x86 on x86), ~~it still has to parse the code to remove any~~ '~~privileged~~ instructions' ~~and replace them with~~ context ~~switches~~. ~~To make it as efficient as possible on~~ x86 Linux, ~~there's a~~ kernel ~~module called~~ KQemu ~~that handles this~~.		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.

	~~Being a~~ kernel ~~module~~, KQemu ~~is able to execute most~~ code ~~unchanged~~, ~~replacing only the lowest-level~~ ring0-only instructions. ~~In that case~~, userspace Qemu ~~still allocates all the~~ RAM ~~for the emulated machine~~, ~~and loads the~~ code. ~~The difference is that instead of recompiling the~~ code, ~~it calls~~ KQemu ~~to scan~~/patch/~~execute it~~. ~~All the peripheral~~ hardware ~~emulation is done in~~ Qemu.		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 perifer dilakukan di Qemu.

	~~This is a lot faster than plain~~ Qemu ~~because most~~ code ~~is unchanged~~, ~~but still has to transform~~ ring0 code (~~most of the~~ code ~~in the~~ VM~~'s kernel~~), ~~so performance still suffers~~.		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==

	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.		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.

Onnowpurbo at 00:03, 8 February 2015

2015-02-08T00:03:25Z

← Older revision		Revision as of 00:03, 8 February 2015
Line 1:		Line 1:

	Qemu:		Qemu:

Onnowpurbo: New page: Qemu: QEmu is a complete and standalone software of its own. You use it to emulate machines, it is very flexible and portable. Mainly it works by a special 'recompiler' that transforms b...

2015-02-04T09:34:32Z

New page: Qemu: QEmu is a complete and standalone software of its own. You use it to emulate machines, it is very flexible and portable. Mainly it works by a special 'recompiler' that transforms b...

New page

Qemu:

QEmu is a complete and standalone software of its own. You use it to emulate machines, it is very flexible and portable. Mainly it works by a special 'recompiler' that transforms binary code written for a given processor into another one (say, to run MIPS code on a PPC mac, or ARM in an x86 PC).

To emulate more than just the processor, Qemu includes a long list of peripheral emulators: disk, network, VGA, PCI, USB, serial/parallel ports, etc.

KQemu:

In the specific case where both source and target are the same architecture (like the common case of x86 on x86), it still has to parse the code to remove any 'privileged instructions' and replace them with context switches. To make it as efficient as possible on x86 Linux, there's a kernel module called KQemu that handles this.

Being a kernel module, KQemu is able to execute most code unchanged, replacing only the lowest-level ring0-only instructions. In that case, userspace Qemu still allocates all the RAM for the emulated machine, and loads the code. The difference is that instead of recompiling the code, it calls KQemu to scan/patch/execute it. All the peripheral hardware emulation is done in Qemu.

This is a lot faster than plain Qemu because most code is unchanged, but still has to transform ring0 code (most of the code in the VM's kernel), so performance still suffers.

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.

==Referensi==

* http://serverfault.com/questions/208693/difference-between-kvm-and-qemu