【原創】Linux虛擬化KVM-Qemu分析(五)之內存虛擬化

背景

  • 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. 概述

《Linux虛擬化KVM-Qemu分析(二)之ARMv8虛擬化》文中描述過內存虛擬化大體框架,再來回顧一下:

  1. 非虛擬化下的內存的訪問

  • CPU訪問物理內存前,需要先建立頁表映射(虛擬地址到物理地址的映射),最終通過查表的方式來完成訪問。在ARMv8中,內核頁表基地址存放在TTBR1_EL1中,用戶空間頁表基地址存放在TTBR0_EL0中;
  1. 虛擬化下的內存訪問

  • 虛擬化情況下,內存的訪問會分爲兩個StageHypervisor通過Stage 2來控制虛擬機的內存視圖,控制虛擬機是否可以訪問某塊物理內存,進而達到隔離的目的;
  • Stage 1VA(Virtual Address)->IPA(Intermediate Physical Address),Host的操作系統控制Stage 1的轉換;
  • Stage 2IPA(Intermediate Physical Address)->PA(Physical Address),Hypervisor控制Stage 2的轉換;

猛一看上邊兩個圖,好像明白了啥,仔細一想,啥也不明白,本文的目標就是將這個過程講明白。

在開始細節講解之前,需要先描述幾個概念:

gva - guest virtual address
gpa - guest physical address
hva - host virtual address
hpa - host physical address

  • Guest OS中的虛擬地址到物理地址的映射,就是典型的常規操作,參考之前的內存管理模塊系列文章;

鋪墊了這麼久,來到了本文的兩個主題:

  1. GPA->HVA;
  2. HVA->HPA;

開始吧!

2. GPA->HVA

還記得上一篇文章《Linux虛擬化KVM-Qemu分析(四)之CPU虛擬化(2)》中的Sample Code嗎?
KVM-Qemu方案中,GPA->HVA的轉換,是通過ioctl中的KVM_SET_USER_MEMORY_REGION命令來實現的,如下圖:

找到了入口,讓我們進一步揭開神祕的面紗。

2.1 數據結構

關鍵的數據結構如下:

  • 虛擬機使用slot來組織物理內存,每個slot對應一個struct kvm_memory_slot,一個虛擬機的所有slot構成了它的物理地址空間;
  • 用戶態使用struct kvm_userspace_memory_region來設置內存slot,在內核中使用struct kvm_memslots結構來將kvm_memory_slot組織起來;
  • struct kvm_userspace_memory_region結構體中,包含了slot的ID號用於查找對應的slot,此外還包含了物理內存起始地址及大小,以及HVA地址,HVA地址是在用戶進程地址空間中分配的,也就是Qemu進程地址空間中的一段區域;

2.2 流程分析

數據結構部分已經羅列了大體的關係,那麼在KVM_SET_USER_MEMORY_REGION時,圍繞的操作就是slots的創建、刪除,更新等操作,話不多說,來圖了:

  • 當用戶要設置內存區域時,最終會調用到__kvm_set_memory_region函數,在該函數中完成所有的邏輯處理;
  • __kvm_set_memory_region函數,首先會對傳入的struct kvm_userspace_memory_region的各個字段進行合法性檢測判斷,主要是包括了地址的對齊,範圍的檢測等;
  • 根據用戶傳遞的slot索引號,去查找虛擬機中對應的slot,查找的結果只有兩種:1)找到一個現有的slot;2)找不到則新建一個slot;
  • 如果傳入的參數中memory_size爲0,那麼會將對應slot進行刪除操作;
  • 根據用戶傳入的參數,設置slot的處理方式:KVM_MR_CREATEKVM_MR_MOVEKVM_MEM_READONLY
  • 根據用戶傳遞的參數決定是否需要分配髒頁的bitmap,標識頁是否可用;
  • 最終調用kvm_set_memslot來設置和更新slot信息;

2.2.1 kvm_set_memslot

具體的memslot的設置在kvm_set_memslot函數中完成,slot的操作流程如下:

  • 首先分配一個新的memslots,並將原來的memslots內容複製到新的memslots中;
  • 如果針對slot的操作是刪除或者移動,首先根據舊的slot id號從memslots中找到原來的slot,將該slot設置成不可用狀態,再將memslots安裝回去。這個安裝的意思,就是RCU的assignment操作,不理解這個的,建議去看看之前的RCU系列文章。由於slot不可用了,需要解除stage2的映射;
  • kvm_arch_prepare_memory_region函數,用於處理新的slot可能跨越多個用戶進程VMA區域的問題,如果爲設備區域,還需要將該區域映射到Guest IPA中;
  • update_memslots用於更新整個memslotsmemslots基於PFN來進行排序的,添加、刪除、移動等操作都是基於這個條件。由於都是有序的,因此可以選擇二分法來進行查找操作;
  • 將添加新的slot後的memslots安裝回KVM中;
  • kvfree用於將原來的memslots釋放掉;

2.2.2 kvm_delete_memslot

kvm_delete_memslot函數,實際就是調用的kvm_set_memslot函數,只是slot的操作設置成KVM_MR_DELETE而已,不再贅述。

3. HVA->HPA

光有了GPA->HVA,似乎還是跟Hypervisor沒有太大關係,到底是怎麼去訪問物理內存的呢?貌似也沒有看到去建立頁表映射啊?
跟我走吧,帶着問題出發!

之前內存管理相關文章中提到過,用戶態程序中分配虛擬地址vma後,實際與物理內存的映射是在page fault時進行的。那麼同樣的道理,我們可以順着這個思路去查找是否HVA->HPA的映射也是在異常處理的過程中創建的?答案是顯然的。

回顧一下前文《Linux虛擬化KVM-Qemu分析(四)之CPU虛擬化(2)》的一張圖片:

  • 當用戶態觸發kvm_arch_vcpu_ioctl_run時,會讓Guest OS去跑在Hypervisor上,當Guest OS中出現異常退出到Host時,此時handle_exit將對退出的原因進行處理;

異常處理函數arm_exit_handlers如下,具體調用選擇哪個處理函數,是根據ESR_EL2, Exception Syndrome Register(EL2)中的值來確定的。

static exit_handle_fn arm_exit_handlers[] = {
	[0 ... ESR_ELx_EC_MAX]	= kvm_handle_unknown_ec,
	[ESR_ELx_EC_WFx]	= kvm_handle_wfx,
	[ESR_ELx_EC_CP15_32]	= kvm_handle_cp15_32,
	[ESR_ELx_EC_CP15_64]	= kvm_handle_cp15_64,
	[ESR_ELx_EC_CP14_MR]	= kvm_handle_cp14_32,
	[ESR_ELx_EC_CP14_LS]	= kvm_handle_cp14_load_store,
	[ESR_ELx_EC_CP14_64]	= kvm_handle_cp14_64,
	[ESR_ELx_EC_HVC32]	= handle_hvc,
	[ESR_ELx_EC_SMC32]	= handle_smc,
	[ESR_ELx_EC_HVC64]	= handle_hvc,
	[ESR_ELx_EC_SMC64]	= handle_smc,
	[ESR_ELx_EC_SYS64]	= kvm_handle_sys_reg,
	[ESR_ELx_EC_SVE]	= handle_sve,
	[ESR_ELx_EC_IABT_LOW]	= kvm_handle_guest_abort,
	[ESR_ELx_EC_DABT_LOW]	= kvm_handle_guest_abort,
	[ESR_ELx_EC_SOFTSTP_LOW]= kvm_handle_guest_debug,
	[ESR_ELx_EC_WATCHPT_LOW]= kvm_handle_guest_debug,
	[ESR_ELx_EC_BREAKPT_LOW]= kvm_handle_guest_debug,
	[ESR_ELx_EC_BKPT32]	= kvm_handle_guest_debug,
	[ESR_ELx_EC_BRK64]	= kvm_handle_guest_debug,
	[ESR_ELx_EC_FP_ASIMD]	= handle_no_fpsimd,
	[ESR_ELx_EC_PAC]	= kvm_handle_ptrauth,
};

用你那雙水汪汪的大眼睛掃描一下這個函數表,發現ESR_ELx_EC_DABT_LOWESR_ELx_EC_IABT_LOW兩個異常,這不就是指令異常和數據異常嗎,我們大膽的猜測,HVA->HPA映射的建立就在kvm_handle_guest_abort函數中。

3.1 kvm_handle_guest_abort

先來補充點知識點,可以更方便的理解接下里的內容:

  1. Guest OS在執行到敏感指令時,產生EL2異常,CPU切換模式並跳轉到EL2el1_syncarch/arm64/kvm/hyp/entry-hyp.S)異常入口;
  2. CPU的ESR_EL2寄存器記錄了異常產生的原因;
  3. Guest退出到kvm後,kvm根據異常產生的原因進行對應的處理。

簡要看一下ESR_EL2寄存器:

  • EC:Exception class,異常類,用於標識異常的原因;
  • ISS:Instruction Specific Syndrome,ISS域定義了更詳細的異常細節;
  • kvm_handle_guest_abort函數中,多處需要對異常進行判斷處理;

kvm_handle_guest_abort函數,處理地址訪問異常,可以分爲兩類:

  1. 常規內存訪問異常,包括未建立頁表映射、讀寫權限等;
  2. IO內存訪問異常,IO的模擬通常需要Qemu來進行模擬;

先看一下kvm_handle_guest_abort函數的註釋吧:

/**
 * kvm_handle_guest_abort - handles all 2nd stage aborts
 *
 * Any abort that gets to the host is almost guaranteed to be caused by a
 * missing second stage translation table entry, which can mean that either the
 * guest simply needs more memory and we must allocate an appropriate page or it
 * can mean that the guest tried to access I/O memory, which is emulated by user
 * space. The distinction is based on the IPA causing the fault and whether this
 * memory region has been registered as standard RAM by user space.
 */
  • 到達Host的abort都是由於缺乏Stage 2頁錶轉換條目導致的,這個可能是Guest需要分配更多內存而必須爲其分配內存頁,或者也可能是Guest嘗試去訪問IO空間,IO操作由用戶空間來模擬的。兩者的區別是觸發異常的IPA地址是否已經在用戶空間中註冊爲標準的RAM;

調用流程來了:

  • kvm_vcpu_trap_get_fault_type用於獲取ESR_EL2的數據異常和指令異常的fault status code,也就是ESR_EL2的ISS域;
  • kvm_vcpu_get_fault_ipa用於獲取觸發異常的IPA地址;
  • kvm_vcpu_trap_is_iabt用於獲取異常類,也就是ESR_EL2EC,並且判斷是否爲ESR_ELx_IABT_LOW,也就是指令異常類型;
  • kvm_vcpu_dabt_isextabt用於判斷是否爲同步外部異常,同步外部異常的情況下,如果支持RAS,Host能處理該異常,不需要將異常注入給Guest;
  • 異常如果不是FSC_FAULTFSC_PERMFSC_ACCESS三種類型的話,直接返回錯誤;
  • gfn_to_memslotgfn_to_hva_memslot_prot這兩個函數,是根據IPA去獲取到對應的memslot和HVA地址,這個地方就對應到了上文中第二章節中地址關係的建立了,由於建立了連接關係,便可以通過IPA去找到對應的HVA;
  • 如果註冊了RAM,能獲取到正確的HVA,如果是IO內存訪問,那麼HVA將會被設置成KVM_HVA_ERR_BADkvm_is_error_hva或者(write_fault && !writable)代表兩種錯誤:1)指令錯誤,向Guest注入指令異常;2)IO訪問錯誤,IO訪問又存在兩種情況:2.1)Cache維護指令,則直接跳過該指令;2.2)正常的IO操作指令,調用io_mem_abort進行IO模擬操作;
  • handle_access_fault用於處理訪問權限問題,如果內存頁無法訪問,則對其權限進行更新;
  • user_mem_abort,用於分配更多的內存,實際上就是完成Stage 2頁表映射的建立,根據異常的IPA地址,已經對應的HVA,建立映射,細節的地方就不表了。

來龍去脈摸清楚了,那就草草收場吧,下回見了。

參考

《Arm Architecture Registers Armv8, for Armv8-A architecture profile》

歡迎關注個人公衆號,不定期分享技術文章。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章