qemulinux內核

❶ KVM、QEMU和KQemu有什麼區別

1、KVM是一套虛擬機管理系統，包括內核虛擬構架和處理器相關模塊，其借用了 QEMU其它一些組件，KVM的非內核部分是由QEMU實現的；載入了模塊後，才能進一步通過其他工具創建虛擬機。

2、QEMU是另外的一套虛擬機管理系統，Kqemu是QEMU的加速器，可以認為是QEMU的一個插件；QEMU可以虛擬出不同架構的虛擬機，如在x86平台上可以虛擬出power機器。

3、KVM負責cpu虛擬化+內存虛擬化，實現了cpu和內存的虛擬化，但KVM不能模擬其他設備。QEMU是模擬IO設備（網卡，磁碟），KVM加上QEMU之後就能實現真正意義上伺服器虛擬化。因為用到了上面兩個東西，所以一般都稱之為QEMU-KVM。

(1)qemulinux內核擴展閱讀：

1、KVM 技術已經從最初的基礎SOHO辦公型，發展成為企業 IT 基礎機房設施管理系統。可以從kvm 客戶端管理軟體輕松的直接訪問位於多個遠程位置的伺服器和設備。

2、QEMU在GNU/Linux平台上使用廣泛。具有高速度及跨平台的特性，通過KQEMU這個閉源的加速器，QEMU能模擬至接近真實電腦的速度。

3、KQEMU現可運行在基於x86或x86_64的Linux2.4或Linux 2.6主機上。

❷ KVM他說的基於內核的虛擬機是什麼意思

這個問題下面好幾個答案是完全錯的，也有些是對的，但寫得很簡單，看相關的討論，估計讀者都沒有讀懂。這里的關鍵問題是概念比較亂，我來幫忙整理一下。

下面的概念定義很多來自我自己的定義，但和現有的概念基本上不會沖突，也應該更容易幫助讀者理解虛擬化技術，所以我猜應該沒有什麼問題。

虛擬化技術，一般理解上，是在一個操作系統之上，模擬另一個操作系統的執行環境。我們看到的各種游戲機模擬器，還有為開發CPU做模擬而做的模擬程序，就是早期比較常見的虛擬化解決方案，它的工作原理很簡單：把CPU的所有寄存器都寫在一組變數中（這組變數我們稱為CPUFile），然後用一片內存當作被模擬CPU的內存（這片內存這里稱為vMEM），然後在用一些數據結構表示IO設備的狀態（這里稱為vIO），三者的數據結構綜合在一起，就是代表一個虛擬化的環境了（這里稱之為VM），之後按順序讀出一條條的指令，根據這個指令的語義，更改VM的數據結構的狀態（如果模擬了硬體，還要模擬硬體的行為，比如發現顯存被寫了一個值，可以在虛擬屏幕上顯示一個點等），這樣，實施虛擬的那個程序就相當於給被虛擬的程序模擬了一台計算機，這種技術，我稱它為「解釋型虛擬化技術」。指令是被一條一條解釋執行的。

在這個方案中，我們有三個對象：
Host：執行虛擬程序的系統
Emulator：實施虛擬的，運行在Host上的那個程序
Guest：被虛擬出來的系統，也就是運行了軟體（例如操作系統）的VM

這些概念在技術演進的過程中會一定程度變化，讀者要注意這一點，記住它的原始含義，否則很容易亂掉。

解釋型虛擬化技術很簡單，直接，概念也容易理解，但很明顯，這個效率是很低的。優化得比較成功的是qemu，它使用一種所謂「編譯型」的技術，把每條被虛擬的設備的指令都寫成一段C代碼，用這段C代碼去修改CPUFile等VM數據，然後再用編譯器去編譯這些C代碼，借用了編譯器的優化能力，最後在解釋Guest的指令的時候，用一個「翻譯區「，把這些C代碼的編譯結果拼起來，然後直接執行。這種方法有效提高了」解釋」的效率（所以qemu才稱為Quick-emulator），但效率很明顯還是非常低的。Android的SDK模擬基於ARM的手機，用的就是這種技術。

隨著技術的發展，有人就開始取巧了：很多時候，我們僅僅是在x86上模擬x86，這些指令何必要一條條解釋執行？我們可以用CPU直接執行這些指令啊，執行到特權指令的時候，我們直接異常，然後在異常中把當前CPU的狀態保存到CPUFile中，然後再解釋執行這個特權指令，這樣不是省去了很多」解釋「的時間了？用這種技術實現的虛擬機，就稱為」調度型虛擬化技術「，這種情況下，Emulator的主要工作就不是解釋了，它的主要工作是調度，調度Host和所有的Guest來分時（或者分核）使用CPU。

qemu也可以工作在這種模式。要工作在這種模式，它需要在內核中插入一個kqemu.ko，以便處理那些特殊的，由它的模擬程序產生的異常。

這種情況下，我們會發現，Emulator已經不是原來那個意思了，雖然我們仍需要使用這個程序，但僅僅靠這個程序，它作為Host上的一個程序，沒有辦法調度Host的資源。所以我們引入另一個實體，所謂Hypervisor，Hypervisor負責調度，Emulator只是給它提請求而已。

（這里，Emulator的語義也發生變更了，讀者有必要注意這一點）

Hypervisor需要掌控整個系統的資源，這樣它就需要有所有設備的驅動，這樣會讓Hypervisor變得非常復雜的。所以Host的概念仍然存在，一種簡化的理解可以是，BIOS啟動Hypervisor，Hypervisor首先啟動第一個OS，那個就是Host，之後Host上的Emulator啟動Guest，Emulator向Hypervisor請求資源，Hypervisor模擬一個環境給新的Guest，但如果Guest向Hypervisor請求IO或者其他特殊能力，這些請求就會被Hypervisor調度到Host上，讓Host執行。

在Xen上，這個Host稱為DOM0，說明Xen是認為Host和Guest在調度上沒有本質區別的，都是一個調度的對象，但DOM0帶有所有的驅動，管理程序也可以放在這里直接和Hypervisor通訊。

好了，現在你可以明白為什麼KVM稱為」內核（K）的VM"技術了，Xen的Hypervisor是一個獨立的部件，由BIOS（其實是grub了）直接載入，然後和DOMx的各個操作系統通訊。而KVM的Hypervisor直接就是內核的一部分，這個Hypervisor的代碼直接就在Linux的內核中，當Host啟動的時候，它們一起載入，一同初始化，只是Hypervisor的代碼工作在虛擬機調度器的狀態，而其他代碼工作在普通內核狀態而已。

這個用ARM64平台特別好理解，ARM64平台（不考慮安全態）3個特權級，EL0用戶態，EL1內核態，EL2 Hypervisor態。這樣，內核啟動先進入EL2，初始化Hypervisor部分的狀態，然後切換入EL1，初始化內核的狀態，然後才fork init，進入EL0。這之後，你啟動qemu-kvm，這個程序就可以通過系統調用（對/dev/kvm文件做ioctl）進入內核，調用KVM的請求，執行調度，從內核中直接做Hypervisor請求，進入Hypervisor要求調度Guest。

這樣，很明顯，KVM確實是」Linux內核提供的虛擬化技術「，這就是它和其他虛擬化技術不同的地方了。

vmware和virtualbox的技術和Xen類似，無論它們如何載入，是否獨立，或者作為一個內核模塊載入，畢竟它們不是內核原始設計的一部分。

至於是全虛擬化（Guest不知道你自己是被模擬的系統），還是Para虛擬化（Guest知道自己是模擬的系統，用直接和Hypervisor通訊的方法實現IO），這個問題和是否KVM沒有關系（kvm兩種模式都可以支持），和性能也沒有關系。這僅僅是構架的不同。

討論區有讀者問，為什麼沒有看到VirtualBox從BIOS載入Hypervisor呢？這個涉及到兩個要素：

第一，kqemu.ko也可以不從BIOS載入，這種模式我仍把kqemu稱為Hypervisor，但這個Hypervisor並非工作在Hypervisor狀態，它是和內核互相妥協從而工作在Hypervisor的角色上的，它的工作級別並不比Host高，但仍可以為Guest模擬出一個運行環境來。VirtualBox使用一樣的技術。

第二，VirtualxBox還可以支持VT-x這樣的硬體加速的虛擬工作狀態。這個事情和VT-x的設計有關，VT-x的特權級繼承自傳統的x86特權級，就是0-3，0是最高優先順序，3是最低優先順序。像Linux就只用了0和3級表示內核和用戶態。剛開始支持虛擬化的時候，Intel考慮0是Hypervisor級（VMM級），1是內核，3是用戶。但這種設計造成不兼容和復雜度。所以到了64位後，新的模式是：系統剛啟動的時候，是Host態0級，在這個級別你可以用VMXON進入VMM級，然後你可以在這個級別創建虛擬機，再用VMXON進入虛擬機，VMXOFF退出虛擬機。虛擬機中仍可以有0-3級。這樣一來，在Host中，你只要能進入0級，就可以把自己提升到VMM級。VirtualBox只要能在內核中插入一個模塊，就可以為自己獲得VMM的許可權。但這個方法在ARM64上是行不通的。

（讀者應該已經注意到了，這裡面的定義在整個發展過程中不斷發生語義的變化，這造成很多人對技術誤解，所以，我們理解計算的概念，更多看我們如何用和如何建模，如果你認為某個概念是持久不變的，基本上你很快就被計算機技術拋棄了。因為基於概念保持部分使用模式不變，然後進行技術演進，是計算機發展的常態）

❸ 使用buildroot編譯arm架構的linux內核，使其支持usb攝像頭，並使用qemu虛擬運行

#沒有吧ext* 和 VFS編進去吧

cd/usr/src/linux
makemenuconfig
#選擇ext4和VFS，在FileSystem里，很好找
make;makemole_install;makeinstall

❹ 究竟是用qemu-kvm還是qemu-system-x86

你好，很高興為你解答！

KVM 只基於內核的虛擬化
Qemu本身就是一種虛擬化，也是一種硬體模擬模擬器
KQemu是Qemu針對於KVM做優化後和KVM的結合，性能比Qemu本身好很多。。。
我們目前說的KVM 其實就是qemu-kvm
在linux中是以一個/dev/kvm的塊設備和qemu-kvm 的一個進程存在的

望採納，謝謝

❺ linux 內核 qemu 相關

缺少了設備樹文件（.dtb）和文件系統。
另外，「--append」選項用了兩個短橫杠。

❻ 有沒什麼工具可以調試Linux內核的

qemu模擬器，內帶gdbserver，可以很方便的源碼調試。
kdb，kgdb之類的也是調試器，最簡單的就是printk看看

❼ qemu怎樣為選擇arm linux內核鏡像選擇運行arm平台

下載Linux內核

下載內核有兩種方法，一種是用git直接下載內核代碼樹，方便後面的內核開發。另一種是直接到內核社區下載對應版本的源碼包。我採用第一種方法，但後面發現主線上3.18版本和後面版本的代碼，使用這種搭建方法運行不起來。目前未查明問題的根因。如果讀者想快速搭建成功，建議選用3.16版本的內核進行搭建。

安裝arm的交叉編譯工具鏈

想必做嵌入式開發的朋友，對交叉編譯工具鏈不陌生。如果你訂制一個交叉編譯工具鏈，建議你使用crosstool-ng開源軟體來構建。但在這里建議直接安裝arm的交叉編譯工具鏈：

sudoapt-getinstallgcc-arm-linux-gnueabi

編譯Linux內核

生成vexpress開發板子的config文件：

makeCROSS_COMPILE=arm-linux-gnueabi-ARCH=armvexpress_defconfig

編譯：

makeCROSS_COMPILE=arm-linux-gnueabi-ARCH=arm

生成的內核鐿像位於arch/arm/boot/zImage，後續qemu啟動時需要使用該鏡像。

下載和安裝qemu模擬器

其實Ubuntu12.04有qemu的安裝包，但由於版本較低，對vexpress開發板支持不友好，建議下載高版本的qemu:

wget

配置qemu前，需要安裝幾個軟體包：

sudoapt-getinstallzlib1g-dev

sudoapt-getinstalllibglib2.0-0

sudoapt-getinstalllibglib2.0-dev

配置qemu，支持模擬arm架構下的所有單板：

./configure--target-list=arm-softmmu--audio-drv-list=

編譯和安裝：

make

makeinstall

測試qemu和內核能否運行成功

qemu已經安裝好了，內核也編譯成功了，到這里最好是測試一下，編譯出來的內核是否OK，或者qemu對vexpress單板支持是否夠友好。

運行命令很簡單：

qemu-system-arm-Mvexpress-a9-m512M-kernel/home/ivan/kernel_git/linux/arch/arm/boot/zImage-nographic-append"console=ttyAMA0"

如果看到內核啟動過程中的列印，說明前的搭建是成功的。

這里簡單介紹下qemu命令的參數：

-Mvexpress-a9模擬vexpress-a9單板，你可以使用-M?參數來獲取該qemu版本支持的所有單板

-m512M單板運行物理內存512M

-kernel/home/ivan/kernel_git/linux/arch/arm/boot/zImage告訴qemu單板運行內核鏡像路徑

-nographic不使用圖形化界面，只使用串口

-append"console=ttyAMA0"內核啟動參數，這里告訴內核vexpress單板運行，串口設備是哪個tty。

注意：

我每次搭建，都忘了內核啟動參數中的console=參數應該填上哪個tty，因為不同單板串口驅動類型不盡相同，創建的tty設備名當然也是不相同的。那vexpress單板的tty設備名是哪個呢？其實這個值可以從生成的.config文件CONFIG_CONSOLE宏找到。

如果搭建其它單板，需要注意內核啟動參數的console=參數值，同樣地，可從生成的.config文件中找到。

製作根文件系統

到這里是否大功告成了呢？其實在上面的測試中，你會發現內核報panic，因為內核找不到根文件系統，無法啟init進程。

根文件系統要考慮兩個方面：

1.根文件系統的內容

如果你看過《LinuxFromScratch》，相信你會對這一步產生恐懼感，但如果一直從事嵌入式開發，就可以放下心來。根文件系統就是簡單得不能再簡單的幾個命令集和態動態而已。為什麼LinuxFromScratch會有那麼復雜，是因為它要製作出一個Linux發生版。但在嵌入式領域，幾乎所有的東西，都是mini版本，根文件系統也不例外。

本文制本的根文件系統=busybox(包含基礎的Linux命令)+運行庫+幾個字元設備

2.根文件系統放在哪裡

其實依賴於每個開發板支持的存儲設備，可以放到NorFlash上，也可以放到SD卡，甚至外部磁碟上。最關鍵的一點是你要清楚知道開發板有什麼存儲設備。

本文直接使用SD卡做為存儲空間，文件格式為ext3格式

下載、編譯和安裝busybox

wget

makedefconfig

makeCROSS_COMPILE=arm-linux-gnueabi-

makeinstallCROSS_COMPILE=arm-linux-gnueabi-

安裝完成後，會在busybox目錄下生成_install目錄，該目錄下的程序就是單板運行所需要的命令。

形成根目錄結構

先在Ubuntu主機環境下，形成目錄結構，裡面存放的文件和目錄與單板上運行所需要的目錄結構完全一樣，然後再打包成鏡像（在開發板看來就是SD卡），這個臨時的目錄結構稱為根目錄

1.創建rootfs目錄（根目錄），根文件系統內的文件全部放到這里

sudomkdirrootfs

2.拷貝busybox命令到根目錄下

sudocpbusybox-1.20.2/_install/*-rrootfs/

3.從工具鏈中拷貝運行庫到lib目錄下

sudocp-P/usr/arm-linux-gnueabi/lib/*rootfs/lib/

4.創建4個tty端終設備

sudomknodrootfs/dev/tty1c41

sudomknodrootfs/dev/tty2c42

sudomknodrootfs/dev/tty3c43

sudomknodrootfs/dev/tty4c44

製作根文件系統鏡像

1.生成32M大小的鏡像

ddif=/dev/zeroof=a9rootfs.ext3bs=1Mcount=32

2.格式化成ext3文件系統

mkfs.ext3a9rootfs.ext3

3.將文件拷貝到鏡像中

sudomkdirtmpfs

sudomount-text3a9rootfs.ext3tmpfs/-oloop

cp-rrootfs/*tmpfs/

sudoumounttmpfs

系統啟動運行

完成上述所有步驟之後，就可以啟動qemu來模擬vexpress開發板了，命令參數如下：

qemu-system-arm-Mvexpress-a9-m512M-kernel/home/ivan/qemu/linux/arch/arm/boot/zImage-nographic-append"root=/dev/mmcblk0console=ttyAMA0"-sda9rootfs.ext3

從內核啟動列印，到命令行提示符出現，激動人心的時刻出現了……

寫在後面的話

通過上面的步驟，搭建出來一個最小的qemu+arm開發環境，你可以上面的基礎上修改內核，或者增加一些測試程序在單板上運行，甚至使用單板的flash設備。

在此，你可以做純arm架構的內核開發，或者與架構無關的內核開發，也可以做單板相關的驅動開發。

❽ 誰看過《Linux 內核完全剖析——基於0.12內核》這本書

Linux-0.12這個目錄把裡面的全部下載就好啊，

❾ qemu能模擬全部x86指令嗎

qemu能模擬全部x86指令。也可以模擬各種ARM板子還可以模擬各種外設，百問網對QEMU做了很多改進支持更多硬體支持更多GUI現實，讓用戶可以更有真實感地使用QEMU來模擬IMX6ULL板子。

qemu模擬全部x86指令的原理

首先Qemu本身並不是KVM的一部分，而是一整套完整的虛擬化解決方案，它是純軟體實現的，包括處理器虛擬化內存虛擬化以及各種虛擬設備的模擬，但因為是純軟體模擬，所以性能相對比較低，而廣義的KVM實際上包含兩部分。

一部分是基於LINUX內核支持的KVM內核模塊，另一部分就是經過簡化和修改Qemu，KVM內核模塊模擬處理器和內存以支持虛擬機的運行，Qemu主要處理I或O以及為用戶提供一個用戶空間工具來進行虛擬機的管理，兩者相互結合相輔相成，構成了一個完整的虛擬化平台。

❿ 如何使用qemu調試linux內核最早版本

gdb是用來調試二進製程序的，不能調試python腳本。 python自帶pdb模塊，可以用來調試自己的腳本。 使用python -m pdb ，交互方式，命令與gdb類似。