【原創】Linux虛擬化KVM-Qemu分析(四)之CPU虛擬化(2)
阿新 • • 發佈:2020-10-11
# 背景
- `Read the fucking source code!` --By 魯迅
- `A picture is worth a thousand words.` --By 高爾基
說明:
1. KVM版本:5.9.1
2. QEMU版本:5.0.0
3. 工具:Source Insight 3.5, Visio
4. 文章同步在部落格園:`https://www.cnblogs.com/LoyenWang/`
# 1. 概述
- 本文圍繞ARMv8 CPU的虛擬化展開;
- 本文會結合Qemu + KVM的程式碼分析,捋清楚上層到底層的脈絡;
- 本文會提供一個Sample Code,用於類比Qemu和KVM的關係,總而言之,大同小異,大題小做,大道至簡,大功告成,大恩不言謝;
先來兩段前戲。
## 1.1 CPU工作原理
AI的世界,程式的執行不再冰冷,CPU對`a.out`說,`hello啊,world已經ok啦,下來return吧!`
既然要說CPU的虛擬化,那就先簡要介紹一下CPU的工作原理:
![](https://img2020.cnblogs.com/blog/1771657/202010/1771657-20201011104448340-2137603419.png)
- CPU的根本任務是執行指令,我們常說的`取指-譯碼-執行-訪存-寫回`,就是典型的指令Pipeline操作;
- 從CPU的功能出發,可以簡要分成三個邏輯模組:
1. `Control Unit`:CPU的指揮中心,協調資料的移動;
2. `ALU`:運算單元,執行CPU內部所有的計算;
3. `Register`:暫存器和`Cache`,都算是CPU內部的儲存單元,其中暫存器可用於儲存需要被譯碼和執行的指令、資料、地址等;
- CPU從記憶體中讀取指令進行譯碼並執行,執行的過程中需要去訪問記憶體中的資料,CPU內部的暫存器可以暫存中間的指令和資料等資訊,通常說的CPU的`context`指的就是CPU暫存器值;
在硬體支援虛擬化之前,Qemu純軟體虛擬化方案,是通過`tcg(tiny code generator)`的方式來進行指令翻譯,翻譯成Host處理器架構的指令來執行。硬體虛擬化技術,是讓虛擬機器能直接執行在Host CPU上,讓Host CPU直接來執行虛擬機器,結合CPU的實際工作原理,應該怎麼來理解呢?來張圖:
![](https://img2020.cnblogs.com/blog/1771657/202010/1771657-20201011104500308-138886064.png)
- CPU通過`pc`暫存器獲取下一條執行指令,進行取指譯碼執行等操作,因此給定CPU一個Context,自然就能控制其執行某些程式碼;
- CPU的虛擬化,最終目標讓虛擬機器執行在CPU上,無非也是要進行CPU的Context切換,控制CPU去執行對應的程式碼,下文會進一步闡述;
既然都講CPU了,那就捎帶介紹下ARMv8的暫存器吧:
1. 通用暫存器:
![](https://img2020.cnblogs.com/blog/1771657/202010/1771657-20201011104509594-1890798486.png)
- 圖中描述的是`EL3`以下,`AArch32`與`AArch64`暫存器對應關係;
- `AArch64`中,總共31個通用暫存器,64bit的為X0-X30,32bit的為W0-W30;
2. 特殊用途暫存器:
![](https://img2020.cnblogs.com/blog/1771657/202010/1771657-20201011104519960-2096557039.png)
- 這些特殊用途的暫存器,主要分為三種:1)存放異常返回地址的`ELR_ELx`;2)各個EL的棧指標`SP_ELx`;3)CPU的狀態相關暫存器;
3. CPU的狀態`PSTATE`:
![](https://img2020.cnblogs.com/blog/1771657/202010/1771657-20201011104530457-40443985.png)
- CPU的狀態在`AArch32`時是通過`CPSR`來獲取,在`AArch64`中,使用`PSTATE`,`PSTATE`不是一個暫存器,它表示的是儲存當前CPU狀態資訊的一組暫存器或一些標誌資訊的統稱;
好了,ARMv8的介紹該打住了,否則要跑偏了。。。
## 1.2 guest模式
![](https://img2020.cnblogs.com/blog/1771657/202010/1771657-20201011104541723-159485278.png)
- Linux系統有兩種執行模式:kernel模式與user模式,為了支援虛擬化功能的CPU,KVM向Linux核心提供了guest模式,用於執行虛擬機器系統非I/O的程式碼;
- user模式,對應的是使用者態執行,Qemu程式就執行在user模式下,並迴圈監聽是否有I/O需要模擬處理;
- kernel模式,執行kvm模組程式碼,負責將CPU切換到VM的執行,其中包含了上下文的load/restore;
- guest模式,本地執行VM的非I/O程式碼,在某些異常情況下會退出該模式,Host OS開始接管;
好了啦,前戲結束,開始直奔主題吧。
# 2. 流程分析
不管你說啥,我上來就是一句中國萬歲,對不起,跑題了。我上來就是一張Qemu初始化流程圖:
![](https://img2020.cnblogs.com/blog/1771657/202010/1771657-20201011104601000-1844983544.png)
- 看過Qemu原始碼的人可能都有種感覺,一開始看好像摸不到門框,這圖簡要畫了下關鍵模組的流程;
- Qemu的原始碼,後續的文章會詳細介紹,本文只focus在`vcpu`相關部分;
除了找到了`qemu_init_vcpu`的入口,這張圖好像跟本文的vcpu的虛擬化關係不是很大,不管了,就算是給後續的Qemu分析打個廣告吧。
## 2.1 vcpu的建立
### 2.1.1 qemu中vcpu建立
![](https://img2020.cnblogs.com/blog/1771657/202010/1771657-20201011104614683-924133375.png)
- Qemu初始化流程圖中,找到了`qemu_init_vcpu`的入口,順著這個`qemu_init_vcpu`就能找到與底層KVM模組互動的過程;
- Qemu中為每個vcpu建立了一個執行緒,操作裝置節點來建立和初始化vcpu;
所以,接力棒甩到了KVM核心模組。
### 2.1.2 kvm中vcpu建立
來一張前文的圖:
![](https://img2020.cnblogs.com/blog/1771657/202010/1771657-20201011104623675-27372564.png)
- 前文中分析過,系統在初始化的時候會註冊字元裝置驅動,設定好了各類操作函式集,等待使用者層的`ioctl`來進行控制;
- `Qemu`中設定`KVM_CREATE_VCPU`,將觸發`kvm_vm_ioctl_create_vcpu`的執行,完成vcpu的建立工作;
![](https://img2020.cnblogs.com/blog/1771657/202010/1771657-20201011104631898-2017289936.png)
- 在底層中進行vcpu的建立工作,主要是分配一個`kvm_vcpu`結構,並且對該結構中的欄位進行初始化;
- 其中有一個用於與應用層進行通訊的資料結構`struct kvm_run`,分配一頁記憶體,應用層會呼叫mmap來進行對映,並且會從該結構中獲取到虛擬機器的退出原因;
- `kvm_arch_vcpu_create`主要完成體系架構相關的初始化,包括timer,pmu,vgic等;
- `create_hyp_mappings`將`kvm_vcpu`結構體建立對映,以便在`Hypervisor`模式下能訪問該結構;
- `create_vcpu_fd`註冊了`kvm_vcpu_fops`操作函式集,針對vcpu進行操作,`Qemu`中設定`KVM_ARM_VCPU_INIT`,將觸發`kvm_arch_vcpu_ioctl_vcpu_init`的執行,完成的工作主要是vcpu的核心暫存器,系統暫存器等的reset操作,此外還包含了上層設定下來的值,放置在`struct kvm_vcpu_init`中;
## 2.2 vcpu的執行
### 2.2.1 qemu中vcpu的執行
![](https://img2020.cnblogs.com/blog/1771657/202010/1771657-20201011104644801-1443039913.png)
- `Qemu`中為每一個vcpu建立一個使用者執行緒,完成了vcpu的初始化後,便進入了vcpu的執行,而這是通過`kvm_cpu_exec`函式來完成的;
- `kvm_cpu_exec`函式中,呼叫`kvm_vcpu_ioctl(,KVM_RUN,)`來讓底層的物理CPU進行執行,並且監測VM的退出,而這個退出原因就是存在放在`kvm_run->exit_reason`中,也就是上文中提到過的應用層與底層互動的機制;
### 2.2.2 kvm中vcpu的執行
使用者層通過`KVM_RUN`命令,將觸發KVM模組中`kvm_arch_vcpu_ioctl_run`函式的執行:
![](https://img2020.cnblogs.com/blog/1771657/202010/1771657-20201011104657586-2025556327.png)
- vcpu最終是要放置在物理CPU上執行的,很顯然,我們需要進行context的切換:儲存好Host的Context,並切換到Guest的Context去執行,最終在退出時再恢復回Host的Context;
- `__guest_enter`函式完成最終的context切換,進入Guest的執行,當Guest退出時,`fixup_guest_exit`將會處理`exit_code`,判斷是否繼續返回Guest執行;
- 當最終Guest退出到Host時,Host呼叫`handle_exit`來處理異常退出,根據`kvm_get_exit_handler`去查詢異常處理函式表對應的處理函式,最終進行執行處理;
# 3. Sample Code
- 上文已經將Qemu+KVM的CPU的虛擬化大概的輪廓已經介紹了,方方面面,問題不大;
- 來一段Sample Code類比Qemu和KVM的關係,在Ubuntu16.04系統上進行測試;
簡要介紹一下:
1. tiny_kernel.S,相當於Qemu中執行的Guest OS,完成的功能很簡單,沒錯,就是`Hello, world`列印;
2. tiny_qemu.c,相當於Qemu,用於載入Guest到vCPU上執行,最終通過kvm放到物理CPU上執行;
魯迅在1921年的時候,說過這麼一句話:`Talk is cheap, show me the code`。
- `tiny_kernel.S`:
```c
start:
/* Hello */
mov $0x48, %al
outb %al, $0xf1
mov $0x65, %al
outb %al, $0xf1
mov $0x6c, %al
outb %al, $0xf1
mov $0x6c, %al
outb %al, $0xf1
mov $0x6f, %al
outb %al, $0xf1
mov $0x2c, %al
outb %al, $0xf1
/* world */
mov $0x77, %al
outb %al, $0xf1
mov $0x6f, %al
outb %al, $0xf1
mov $0x72, %al
outb %al, $0xf1
mov $0x6c, %al
outb %al, $0xf1
mov $0x64, %al
outb %al, $0xf1
mov $0x0a, %al
outb %al, $0xf1
hlt
```
- `tiny_qemu.c`:
```c
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define KVM_DEV "/dev/kvm"
#define TINY_KERNEL_FILE "./tiny_kernel.bin"
#define PAGE_SIZE 0x1000
int main(void)
{
int kvm_fd;
int vm_fd;
int vcpu_fd;
int tiny_kernel_fd;
int ret;
int mmap_size;
struct kvm_sregs sregs;
struct kvm_regs regs;
struct kvm_userspace_memory_region mem;
struct kvm_run *kvm_run;
void *userspace_addr;
/* open kvm device */
kvm_fd = open(KVM_DEV, O_RDWR);
assert(kvm_fd > 0);
/* create VM */
vm_fd = ioctl(kvm_fd, KVM_CREATE_VM, 0);
assert(vm_fd >= 0);
/* create VCPU */
vcpu_fd = ioctl(vm_fd, KVM_CREATE_VCPU, 0);
assert(vcpu_fd >= 0);
/* open tiny_kernel binary file */
tiny_kernel_fd = open(TINY_KERNEL_FILE, O_RDONLY);
assert(tiny_kernel_fd > 0);
/* map 4K into memory */
userspace_addr = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS, -1, 0);
assert(userspace_addr > 0);
/* read tiny_kernel binary into the memory */
ret = read(tiny_kernel_fd, userspace_addr, PAGE_SIZE);
assert(ret >= 0);
/* set user memory region */
mem.slot = 0;
mem.flags = 0;
mem.guest_phys_addr = 0;
mem.memory_size = PAGE_SIZE;
mem.userspace_addr = (unsigned long)userspace_addr;
ret = ioctl(vm_fd, KVM_SET_USER_MEMORY_REGION, &mem);
assert(ret >= 0);
/* get kvm_run */
mmap_size = ioctl(kvm_fd, KVM_GET_VCPU_MMAP_SIZE, NULL);
assert(mmap_size >= 0);
kvm_run = (struct kvm_run *)mmap(NULL, mmap_size, PROT_READ | PROT_WRITE, MAP_SHARED, vcpu_fd, 0);
assert(kvm_run >= 0);
/* set cpu registers */
ret = ioctl(vcpu_fd, KVM_GET_SREGS, &sregs);
assert(ret >= 0);
sregs.cs.base = 0;
sregs.cs.selector = 0;
ret = ioctl(vcpu_fd, KVM_SET_SREGS, &sregs);
memset(®s, 0, sizeof(struct kvm_regs));
regs.rip = 0;
ret = ioctl(vcpu_fd, KVM_SET_REGS, ®s);
assert(ret >= 0);
/* vcpu run */
while (1) {
ret = ioctl(vcpu_fd, KVM_RUN, NULL);
assert(ret >= 0);
switch(kvm_run->exit_reason) {
case KVM_EXIT_HLT:
printf("----KVM EXIT HLT----\n");
close(kvm_fd);
close(tiny_kernel_fd);
return 0;
case KVM_EXIT_IO:
putchar(*(((char *)kvm_run) + kvm_run->io.data_offset));
break;
default:
printf("Unknow exit reason: %d\n", kvm_run->exit_reason);
break;
}
}
return 0;
}
```
為了表明我沒有騙人,上一張在Ubuntu16.04的虛擬機器上執行的結果圖吧:
![](https://img2020.cnblogs.com/blog/1771657/202010/1771657-20201011104712313-1064794656.png)
草草收工吧。
# 4. 參考
`ARMv8-A Architecture Overview`
`ARMv8 Techinology Preview`
`Arm Architecture Reference Manual, Armv8, for Armv8-A architecture profile`
` Virtual lockstep for fault tolerance and architectural vulnerability analysis`
歡迎關注個人公眾號,不定期分享技術文章:
![](https://img2020.cnblogs.com/blog/1771657/202010/1771657-20201011104741893-4683966