# 背景 - `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. 概述 本文會將ARM GICv2中斷虛擬化的總體框架和流程講清楚，這個曾經困擾我好幾天的問題在被捋清的那一刻，讓我有點`每有會意，欣然忘食`的感覺。 在講述中斷虛擬化之前，我們應該對中斷的作用與處理流程有個大致的瞭解：  - 中斷是處理器用於非同步處理外圍裝置請求的一種機制； - 外設通過硬體管腳連線在中斷控制器上，並通過電訊號向中斷控制器傳送請求； - 中斷控制器將外設的中斷請求路由到CPU上； - CPU（以ARM為例）進行模式切換（切換到IRQ/FIQ），儲存Context後，根據外設的中斷號去查詢系統中已經註冊好的Handler進行處理，處理完成後再將Context進行恢復，接著之前打斷的執行流繼續move on； - 中斷的作用不侷限於外設的處理，系統的排程，SMP核間互動等，都離不開中斷；   中斷虛擬化，將從中斷訊號產生到路由到vCPU的角度來展開，包含以下三種情況： 1. 物理裝置產生中斷訊號，路由到vCPU； 2. 虛擬外設產生中斷訊號，路由到vCPU； 3. Guest OS中CPU之間產生中斷訊號（IPI中斷）； 本文將圍繞`ARM-GICv2`來描述，因此也不會涉及到`MSI`以及`ITS`等特性，帶著問題出發吧。 # 2. VGIC - 在講中斷虛擬化之前，有必要先講一下ARMv8中Hypervisor的架構，因為涉及到不同的Exception Level的切換； - 在我閱讀原始碼時，根據程式碼去匹配某篇Paper中的理論時，出現了一些理解偏差，曾一度困擾了我好幾天;  - `Non-VHE` 1. Linux ARM架構的Hypervisor在引入時，採用的是左圖中的系統架構，以便能充分利用Linux現有的機制，比如scheduler等； 2. KVM/ARM的實現採用了`split`模式，分成`Highvisor`和`Lowvisor`，這樣可以充分利用ARM處理器不同模式的好處，比如，`Highvisor`可以利用Linux Kernel的現有機制，而`Lowvisor`又可以利用`Hyp Mode`的特權。此外，帶來的好處還包含了不需要大量修改Linux核心的程式碼，這個在剛引入的時候是更容易被社群所接受的； 3. `Lowvisor`有三個關鍵功能：1）對不同的執行Context進行隔離與保護，比如VM之間不會相互影響；2）提供Guest和Host的相互切換，也就是所謂的`world switch`；3）提供一個虛擬化`trap handler`，用於處理trap到Hypervisor的中斷和異常；   - `VHE` 1. `VHE: Virtualization Host Extensions`，用於支援Host OS執行在EL2上，Hypervisor和Host OS都執行在EL2，可以減少Context切換帶來的開銷； 2. 目前`Cortex-A55, Cortex-A75, Cortex-A76`支援VHE，其中VHE的控制是通過`HCR_EL2`暫存器的操作來實現的；   再補充一個知識點： 1. Host如果執行在EL1時，可以通過`HVC（Hypervisor Call）`指令，主動trap到EL2中，從而由Hypervisor來接管； 2. Guest OS可以配置成當有中斷或異常時trap到EL2中，在中斷或異常產生時，trap到EL2中，從而由Hypervisor來接管； 3. EL2可以通過`eret`指令，退回到EL1； 本文的討論基於`Non-VHE`系統。 ## 2.1 GIC虛擬化支援 GICv2硬體支援虛擬化，來一張舊圖：  先看一下物理GIC的功能模組： - GIC分成兩部分：`Distributor`和`CPU Interfaces`，`Distributor`和`CPU Interfaces`都是通過MMIO的方式來進行訪問； - `Distributor`用於配置GIC，比如中斷的enable與disable，SMP中的IPI中斷、CPU affinity，優先順序處理等； - `CPU Interfaces`用於連線CPU，進行中斷的ACK（Acknowledge）以及EOI（End-Of-Interrupt）訊號處理等，比如當CPU收到中斷訊號時，會通過`CPU Interfaces`進行ACK迴應，並且在處理完中斷後寫入EOI暫存器，而在寫EOI之前將不再收到該中斷； 簡化圖如下：  GICv2，提供了硬體上的虛擬化支援，也就是虛擬GIC（VGIC），從而中斷的接收不需要通過Hypervisor來軟體模擬： 1. 針對每個vCPU，VGIC引入了`VGIC CPU Interfaces`和對應的Hypervisor控制介面； 2. 可以通過寫Hypervisor控制介面中的LR（List Register）暫存器來產生虛擬中斷，`VGIC CPU Interface`會將虛擬中斷訊號送入到Guest中； 3. `VGIC CPU Interface`支援`ACK`和`EOI`，因此這些操作也不需要trap到Hypervisor中來通過軟體進行模擬，也減少了CPU接收中斷的overhead； 4. `Distributor`仍然需要trap到Hypervisor中來進行軟體模擬，比如，當某個vCPU需要傳送虛擬IPI到另一個vCPU時，此時是需要`Distributor`來輔助完成功能的，這個過程就需要trap到Hypervisor； ## 2.2 虛擬中斷產生流程 本文開始提到的三種中斷訊號源，如下圖所示：  - ①：物理外設產生虛擬中斷流程： 1. 外設中斷訊號（Hypervisor已經將其配置成虛擬中斷）到達GIC； 2. GIC Distributor將該物理IRQ傳送至CPU； 3. CPU trap到Hyp模式，此時將會退出Guest OS的執行，並返回到Host OS； 4. Host OS將響應該物理中斷，也就是Host OS驅動響應外設中斷訊號； 5. Hypervisor往`List Register`寫入虛擬中斷，Virtual CPU interface將virtual irq訊號傳送至vCPU； 6. CPU將處理該異常，Guest OS會從Virtual CPU Interface讀取中斷狀態進行響應；   - ②：虛擬外設產生虛擬中斷流程： 1. Qemu模擬外設，通過`irqfd`來觸發`Hypervisor`進行中斷注入； 2. Hypervisor往`List Register`寫入虛擬中斷，Virtual CPU interface將virtual irq訊號傳送至vCPU； 3. CPU將處理該異常，Guest OS會從Virtual CPU Interface讀取中斷狀態進行響應；   - ③：vCPU IPI中斷流程： 1. Guest OS訪問Virtual Distributor，觸發異常，trap到Hypervisor； 2. Hypervisor進行IO異常響應，並最終將虛擬中斷寫入到List Register中，Virtual CPU interface將virtual irq訊號傳送至vCPU； 3. CPU將處理該異常，Guest OS會從Virtual CPU Interface讀取中斷狀態進行響應；   上述描述的流程，實際中需要和虛擬外設去互動，包括虛擬外設框架（比如`VFIO`）等，而本文只是從中斷的角度來分析，省去了外設部分。   理論部分講完了，下邊就開始從原始碼中去印證理論了。 # 3. 軟體實現流程 ## 3.1 VGIC初始化  - `kvm_init`為總入口，進入`vgic_v2_probe`函式，完成GICv2的初始化操作，此處還會跟`GICV2`核心中的驅動互動，去獲取`gic_kvm_info`資訊，主要包括基地址資訊等，便於後續操作中去進行配置操作； - 從藍色部分的函式呼叫可以看出，初始化完成後，會註冊一個`kvm_device_ops`的操作函式集，以便響應使用者層的`ioctl`操作； - 使用者層呼叫`ioctl(vm_fd, KVM_CREATE_DEVICE, 0)`，最終將呼叫`vgic_create`函式，完成VGIC裝置的建立，在該建立函式中也會註冊`kvm_device_fops`操作函式集，用於裝置屬性的設定和獲取； - 使用者層通過`ioctl(dev_fd, KVM_SET_DEVICE_ATTR, 0)/ioctl(dev_fd, KVM_GET_DEVICE_ATTR, 0)`來進行屬性的設定和獲取，最終也會呼叫`vgic_v2_set_attr/vgic_v2_get_attr`，以便完成對VGIC的設定； ## 3.2 物理外設產生中斷 假設你已經看過之前CPU的虛擬化文章了，按照慣例，先上圖：  - 先來一個先決條件： `HCR_EL2.IMO`設定為1，所有的IRQ都將trap到Hyp模式，因此，當Guest OS執行在vCPU上時，物理外設觸發中斷訊號時，此時將切換到EL2，然後執行`el1_irq`； - 在Host中，當用戶態通過`KVM_RUN`控制vCPU執行時，在`kvm_call_hyp_ret`將觸發Exception Level的切換，切換到Hyp模式並呼叫`__kvm_vcpu_run_nvhe`，在該函式中`__guest_enter`將切換到Guest OS的context，並最終通過`eret`返回到EL1，Guest OS正式開始執行； - 中斷觸發後`el1_irq`將執行`__guest_exit`，這個過程將進行Context切換，也就是跳轉到Host切入Guest的那個點，恢復Host的執行。注意了，這裡邊有個點很迷惑，`el1_irq`和`__guest_exit`的執行都是在EL2中，而Host在EL1執行，之前我一直沒有找到`eret`來進行Exception Level的切換，最終發現原來是`kvm_call_hyp_ret`呼叫時，去異常向量表中找到對應的執行函式，實際會呼叫`do_el2_call`，在該函式中完成了Exception Level的切換，最終回到了EL1； - 切回到Host中時，當`local_irq_enable`開啟中斷後，物理pending的中斷就可以被Host歡快的響應了；   那虛擬中斷是什麼時候注入的呢？沒錯，圖中的`kvm_vgic_flush_hwstate`會將虛擬中斷注入，並且在`__guest_enter`切換回Guest OS時進行響應：  - `vgic_cpu`結構體中的`ap_list_head`連結串列用於存放Active和Pending狀態的中斷，這也就是命名為`ap_list_head`的原因； - `kvm_vgic_flush_hwstate`函式會遍歷`ap_list_head`中的中斷資訊，並填入到`vgic_lr`陣列中，最終會通過`vgic_restore_state`函式將陣列中的內容更新到GIC的硬體中，也就完成了中斷的注入了，當`__guest_enter`執行後，切換到Guest OS，便可以響應虛擬中斷了； - 當從Guest OS退出後，此時需要呼叫`kvm_vgic_sync_hwstate`，這個操作相當於`kvm_vgic_flush_hwstate`的逆操作，將硬體資訊進行儲存，並對短期內不會處理的中斷進行剔除； ## 3.3 虛擬外設產生中斷  - irqfd提供了一種機制用於注入虛擬中斷，而這個中斷源可以來自虛擬外設； - irqfd是基於eventfd的機制來實現的，用於使用者態與核心態，以及核心態之間的事件通知； - 事件源可以是虛擬裝置，比如VFIO框架等，這個模組還沒有去深入瞭解過，不敢妄言，後續系列會跟進；   軟體流程如下圖：  - 初始化的操作包括兩部分：1）設定Routing entry（【a】vgic_init初始化的時候建立預設的entry；【b】：使用者層通過KVM_SET_GSI_ROUTING來設定）；2）設定irqfd； - 初始化設定完成後，系統可以隨時響應事件觸發了，當事件源觸發時，將排程到`irqfd_inject`函式； - `irqfd_inject`函式完成虛擬中斷的注入操作，在該函式中會去回撥`set`函式，而`set`函式是在`Routing entry`初始化的時候設定好的； - 實際的注入操作在`vgic_irqfd_set_irq`函式中完成； - `kvm_vcpu_kick`函式，將Guest OS切回到Host OS，中斷注入後再切回到Guest OS就可以響應了； ## 3.4 vCPU IPI  - Host對VGIC的`Distributor`進行了模擬，當Guest嘗試訪問`VGIC Distributor`時，將觸發異常操作，trap到Hyp模式； - Hypervisor對異常進行處理，完成寫入操作，並最終切回到Guest OS進行響應； - 簡單來說，Hypervisor就是要對中斷進行管理，沒錯，就是這麼強勢；   軟體流程如下：  - 上層呼叫`ioctl(vcpu_fd, KVM_RUN, 0)`時，最終將呼叫到`vgic_register_dist_iodev`函式，該函式完成的作用就是將VGIC的`Distributor`註冊為IO裝置，以便給Guest OS來進行訪問； - `vgic_register_dist_iodev`分為兩個功能模組：1）初始化`struct vgic_registers_region`結構體欄位和操作函式集；2）註冊為MMIO匯流排裝置； - `struct vgic_registers_region`定義好了不同的暫存器區域，以及相應的讀寫函式，`vgic_v2_dist_registers`陣列最終會提供給`dispach_mmio_read/dispach_mmio_write`函式來查詢與呼叫； - 當Guest OS訪問`Distributor`時，觸發IO異常並切換回Host進行處理，`io_mem_abort`會根據匯流排的型別（MMIO）去查詢到對應的讀寫函式進行操作，也就是圖中對應的`dispatch_mmio_read/dispach_mmio_write`函式，最終完成暫存器區域的讀寫； - 圖中的紅色線，代表的就是異常處理的執行流，可以說是一目瞭然了。   耗時耗力耗心血的一篇文章終於寫完了，ARMv8 GICv2中斷虛擬化的總體框架和流程應該算是理順了，全網相關主題的文章並不多，希望能給帶來點幫助吧。 如果對你有用的話，在看，分享，打賞三連吧。 # 參考 `《arm_gic_architecture_specification》` `《ARM_Interrupt_Virtualization》` `《VM-Support-ARM》` `《CoreLink GIC-400 Generic Interrupt Controller》` `《Virtualization in the ARM Architecture》` `https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=721eecbf4fe995ca94a9edec0c9843b1cc0eaaf3` 歡迎關注個人公眾號，不定期更新核心相關技術文章 ![](https://img2020.cnblogs.com/blog/1771657/202011/1771657-20201121200444299-4635962