背景
Read the fucking source code! --By 魯迅
A picture is worth a thousand words. --By 高爾基
說明:
- KVM版本:5.9.1
- QEMU版本:5.0.0
- 工具:Source Insight 3.5, Visio
- 文章同步在博客園:
https://www.cnblogs.com/LoyenWang/
1. 概述
本文會將ARM GICv2中斷虛擬化的總體框架和流程講清楚,這個曾經(jīng)困擾我好幾天的問題在被捋清的那一刻,讓我有點(diǎn)每有會意,欣然忘食 的感覺。
在講述中斷虛擬化之前,我們應(yīng)該對中斷的作用與處理流程有個大致的了解:

- 中斷是處理器用于異步處理外圍設(shè)備請求的一種機(jī)制;
- 外設(shè)通過硬件管腳連接在中斷控制器上,并通過電信號向中斷控制器發(fā)送請求;
- 中斷控制器將外設(shè)的中斷請求路由到CPU上;
- CPU(以ARM為例)進(jìn)行模式切換(切換到IRQ/FIQ),保存Context后,根據(jù)外設(shè)的中斷號去查找系統(tǒng)中已經(jīng)注冊好的Handler進(jìn)行處理,處理完成后再將Context進(jìn)行恢復(fù),接著之前打斷的執(zhí)行流繼續(xù)move on;
- 中斷的作用不局限于外設(shè)的處理,系統(tǒng)的調(diào)度,SMP核間交互等,都離不開中斷;
中斷虛擬化,將從中斷信號產(chǎn)生到路由到vCPU的角度來展開,包含以下三種情況:
- 物理設(shè)備產(chǎn)生中斷信號,路由到vCPU;
- 虛擬外設(shè)產(chǎn)生中斷信號,路由到vCPU;
- Guest OS中CPU之間產(chǎn)生中斷信號(IPI中斷);
本文將圍繞ARM-GICv2 來描述,因此也不會涉及到MSI 以及ITS 等特性,帶著問題出發(fā)吧。
2. VGIC
- 在講中斷虛擬化之前,有必要先講一下ARMv8中Hypervisor的架構(gòu),因?yàn)樯婕暗讲煌腅xception Level的切換;
- 在我閱讀源代碼時,根據(jù)代碼去匹配某篇Paper中的理論時,出現(xiàn)了一些理解偏差,曾一度困擾了我好幾天;

Non-VHE
- Linux ARM架構(gòu)的Hypervisor在引入時,采用的是左圖中的系統(tǒng)架構(gòu),以便能充分利用Linux現(xiàn)有的機(jī)制,比如scheduler等;
- KVM/ARM的實(shí)現(xiàn)采用了
split 模式,分成Highvisor 和Lowvisor ,這樣可以充分利用ARM處理器不同模式的好處,比如,Highvisor 可以利用Linux Kernel的現(xiàn)有機(jī)制,而Lowvisor 又可以利用Hyp Mode 的特權(quán)。此外,帶來的好處還包含了不需要大量修改Linux內(nèi)核的代碼,這個在剛引入的時候是更容易被社區(qū)所接受的;
Lowvisor 有三個關(guān)鍵功能:1)對不同的執(zhí)行Context進(jìn)行隔離與保護(hù),比如VM之間不會相互影響;2)提供Guest和Host的相互切換,也就是所謂的world switch ;3)提供一個虛擬化trap handler ,用于處理trap到Hypervisor的中斷和異常;
VHE
VHE: Virtualization Host Extensions ,用于支持Host OS運(yùn)行在EL2上,Hypervisor和Host OS都運(yùn)行在EL2,可以減少Context切換帶來的開銷;
- 目前
Cortex-A55, Cortex-A75, Cortex-A76 支持VHE,其中VHE的控制是通過HCR_EL2 寄存器的操作來實(shí)現(xiàn)的;
?
再補(bǔ)充一個知識點(diǎn):
- Host如果運(yùn)行在EL1時,可以通過
HVC(Hypervisor Call) 指令,主動trap到EL2中,從而由Hypervisor來接管;
- Guest OS可以配置成當(dāng)有中斷或異常時trap到EL2中,在中斷或異常產(chǎn)生時,trap到EL2中,從而由Hypervisor來接管;
- EL2可以通過
eret 指令,退回到EL1;
本文的討論基于Non-VHE 系統(tǒng)。
2.1 GIC虛擬化支持
GICv2硬件支持虛擬化,來一張舊圖:

先看一下物理GIC的功能模塊:
- GIC分成兩部分:
Distributor 和CPU Interfaces ,Distributor 和CPU Interfaces 都是通過MMIO的方式來進(jìn)行訪問;
Distributor 用于配置GIC,比如中斷的enable與disable,SMP中的IPI中斷、CPU affinity,優(yōu)先級處理等;
CPU Interfaces 用于連接CPU,進(jìn)行中斷的ACK(Acknowledge)以及EOI(End-Of-Interrupt)信號處理等,比如當(dāng)CPU收到中斷信號時,會通過CPU Interfaces 進(jìn)行ACK回應(yīng),并且在處理完中斷后寫入EOI寄存器,而在寫EOI之前將不再收到該中斷;
簡化圖如下:

GICv2,提供了硬件上的虛擬化支持,也就是虛擬GIC(VGIC),從而中斷的接收不需要通過Hypervisor來軟件模擬:
- 針對每個vCPU,VGIC引入了
VGIC CPU Interfaces 和對應(yīng)的Hypervisor控制接口;
- 可以通過寫Hypervisor控制接口中的LR(List Register)寄存器來產(chǎn)生虛擬中斷,
VGIC CPU Interface 會將虛擬中斷信號送入到Guest中;
VGIC CPU Interface 支持ACK 和EOI ,因此這些操作也不需要trap到Hypervisor中來通過軟件進(jìn)行模擬,也減少了CPU接收中斷的overhead;
Distributor 仍然需要trap到Hypervisor中來進(jìn)行軟件模擬,比如,當(dāng)某個vCPU需要發(fā)送虛擬IPI到另一個vCPU時,此時是需要Distributor 來輔助完成功能的,這個過程就需要trap到Hypervisor;
2.2 虛擬中斷產(chǎn)生流程
本文開始提到的三種中斷信號源,如下圖所示:

- ①:物理外設(shè)產(chǎn)生虛擬中斷流程:
- 外設(shè)中斷信號(Hypervisor已經(jīng)將其配置成虛擬中斷)到達(dá)GIC;
- GIC Distributor將該物理IRQ發(fā)送至CPU;
- CPU trap到Hyp模式,此時將會退出Guest OS的運(yùn)行,并返回到Host OS;
- Host OS將響應(yīng)該物理中斷,也就是Host OS驅(qū)動響應(yīng)外設(shè)中斷信號;
- Hypervisor往
List Register 寫入虛擬中斷,Virtual CPU interface將virtual irq信號發(fā)送至vCPU;
- CPU將處理該異常,Guest OS會從Virtual CPU Interface讀取中斷狀態(tài)進(jìn)行響應(yīng);
?
- ②:虛擬外設(shè)產(chǎn)生虛擬中斷流程:
- Qemu模擬外設(shè),通過
irqfd 來觸發(fā)Hypervisor 進(jìn)行中斷注入;
- Hypervisor往
List Register 寫入虛擬中斷,Virtual CPU interface將virtual irq信號發(fā)送至vCPU;
- CPU將處理該異常,Guest OS會從Virtual CPU Interface讀取中斷狀態(tài)進(jìn)行響應(yīng);
?
- ③:vCPU IPI中斷流程:
- Guest OS訪問Virtual Distributor,觸發(fā)異常,trap到Hypervisor;
- Hypervisor進(jìn)行IO異常響應(yīng),并最終將虛擬中斷寫入到List Register中,Virtual CPU interface將virtual irq信號發(fā)送至vCPU;
- CPU將處理該異常,Guest OS會從Virtual CPU Interface讀取中斷狀態(tài)進(jìn)行響應(yīng);
上述描述的流程,實(shí)際中需要和虛擬外設(shè)去交互,包括虛擬外設(shè)框架(比如VFIO )等,而本文只是從中斷的角度來分析,省去了外設(shè)部分。
理論部分講完了,下邊就開始從源碼中去印證理論了。
3. 軟件實(shí)現(xiàn)流程
3.1 VGIC初始化

kvm_init 為總?cè)肟冢M(jìn)入vgic_v2_probe 函數(shù),完成GICv2的初始化操作,此處還會跟GICV2 內(nèi)核中的驅(qū)動交互,去獲取gic_kvm_info 信息,主要包括基地址信息等,便于后續(xù)操作中去進(jìn)行配置操作;
- 從藍(lán)色部分的函數(shù)調(diào)用可以看出,初始化完成后,會注冊一個
kvm_device_ops 的操作函數(shù)集,以便響應(yīng)用戶層的ioctl 操作;
- 用戶層調(diào)用
ioctl(vm_fd, KVM_CREATE_DEVICE, 0) ,最終將調(diào)用vgic_create 函數(shù),完成VGIC設(shè)備的創(chuàng)建,在該創(chuàng)建函數(shù)中也會注冊kvm_device_fops 操作函數(shù)集,用于設(shè)備屬性的設(shè)置和獲??;
- 用戶層通過
ioctl(dev_fd, KVM_SET_DEVICE_ATTR, 0)/ioctl(dev_fd, KVM_GET_DEVICE_ATTR, 0) 來進(jìn)行屬性的設(shè)置和獲取,最終也會調(diào)用vgic_v2_set_attr/vgic_v2_get_attr ,以便完成對VGIC的設(shè)置;
3.2 物理外設(shè)產(chǎn)生中斷
假設(shè)你已經(jīng)看過之前CPU的虛擬化文章了,按照慣例,先上圖:

- 先來一個先決條件:
HCR_EL2.IMO 設(shè)置為1,所有的IRQ都將trap到Hyp模式,因此,當(dāng)Guest OS運(yùn)行在vCPU上時,物理外設(shè)觸發(fā)中斷信號時,此時將切換到EL2,然后執(zhí)行el1_irq ;
- 在Host中,當(dāng)用戶態(tài)通過
KVM_RUN 控制vCPU運(yùn)行時,在kvm_call_hyp_ret 將觸發(fā)Exception Level的切換,切換到Hyp模式并調(diào)用__kvm_vcpu_run_nvhe ,在該函數(shù)中__guest_enter 將切換到Guest OS的context,并最終通過eret 返回到EL1,Guest OS正式開始運(yùn)行;
- 中斷觸發(fā)后
el1_irq 將執(zhí)行__guest_exit ,這個過程將進(jìn)行Context切換,也就是跳轉(zhuǎn)到Host切入Guest的那個點(diǎn),恢復(fù)Host的執(zhí)行。注意了,這里邊有個點(diǎn)很迷惑,el1_irq 和__guest_exit 的執(zhí)行都是在EL2中,而Host在EL1執(zhí)行,之前我一直沒有找到eret 來進(jìn)行Exception Level的切換,最終發(fā)現(xiàn)原來是kvm_call_hyp_ret 調(diào)用時,去異常向量表中找到對應(yīng)的執(zhí)行函數(shù),實(shí)際會調(diào)用do_el2_call ,在該函數(shù)中完成了Exception Level的切換,最終回到了EL1;
- 切回到Host中時,當(dāng)
local_irq_enable 打開中斷后,物理pending的中斷就可以被Host歡快的響應(yīng)了;
那虛擬中斷是什么時候注入的呢?沒錯,圖中的kvm_vgic_flush_hwstate 會將虛擬中斷注入,并且在__guest_enter 切換回Guest OS時進(jìn)行響應(yīng):

vgic_cpu 結(jié)構(gòu)體中的ap_list_head 鏈表用于存放Active和Pending狀態(tài)的中斷,這也就是命名為ap_list_head 的原因;
kvm_vgic_flush_hwstate 函數(shù)會遍歷ap_list_head 中的中斷信息,并填入到vgic_lr 數(shù)組中,最終會通過vgic_restore_state 函數(shù)將數(shù)組中的內(nèi)容更新到GIC的硬件中,也就完成了中斷的注入了,當(dāng)__guest_enter 執(zhí)行后,切換到Guest OS,便可以響應(yīng)虛擬中斷了;
- 當(dāng)從Guest OS退出后,此時需要調(diào)用
kvm_vgic_sync_hwstate ,這個操作相當(dāng)于kvm_vgic_flush_hwstate 的逆操作,將硬件信息進(jìn)行保存,并對短期內(nèi)不會處理的中斷進(jìn)行剔除;
3.3 虛擬外設(shè)產(chǎn)生中斷

- irqfd提供了一種機(jī)制用于注入虛擬中斷,而這個中斷源可以來自虛擬外設(shè);
- irqfd是基于eventfd的機(jī)制來實(shí)現(xiàn)的,用于用戶態(tài)與內(nèi)核態(tài),以及內(nèi)核態(tài)之間的事件通知;
- 事件源可以是虛擬設(shè)備,比如VFIO框架等,這個模塊還沒有去深入了解過,不敢妄言,后續(xù)系列會跟進(jìn);
軟件流程如下圖:

- 初始化的操作包括兩部分:1)設(shè)置Routing entry(【a】vgic_init初始化的時候創(chuàng)建默認(rèn)的entry;【b】:用戶層通過KVM_SET_GSI_ROUTING來設(shè)置);2)設(shè)置irqfd;
- 初始化設(shè)置完成后,系統(tǒng)可以隨時響應(yīng)事件觸發(fā)了,當(dāng)事件源觸發(fā)時,將調(diào)度到
irqfd_inject 函數(shù);
irqfd_inject 函數(shù)完成虛擬中斷的注入操作,在該函數(shù)中會去回調(diào)set 函數(shù),而set 函數(shù)是在Routing entry 初始化的時候設(shè)置好的;
- 實(shí)際的注入操作在
vgic_irqfd_set_irq 函數(shù)中完成;
kvm_vcpu_kick 函數(shù),將Guest OS切回到Host OS,中斷注入后再切回到Guest OS就可以響應(yīng)了;
3.4 vCPU IPI

- Host對VGIC的
Distributor 進(jìn)行了模擬,當(dāng)Guest嘗試訪問VGIC Distributor 時,將觸發(fā)異常操作,trap到Hyp模式;
- Hypervisor對異常進(jìn)行處理,完成寫入操作,并最終切回到Guest OS進(jìn)行響應(yīng);
- 簡單來說,Hypervisor就是要對中斷進(jìn)行管理,沒錯,就是這么強(qiáng)勢;
軟件流程如下:

- 上層調(diào)用
ioctl(vcpu_fd, KVM_RUN, 0) 時,最終將調(diào)用到vgic_register_dist_iodev 函數(shù),該函數(shù)完成的作用就是將VGIC的Distributor 注冊為IO設(shè)備,以便給Guest OS來進(jìn)行訪問;
vgic_register_dist_iodev 分為兩個功能模塊:1)初始化struct vgic_registers_region 結(jié)構(gòu)體字段和操作函數(shù)集;2)注冊為MMIO總線設(shè)備;
struct vgic_registers_region 定義好了不同的寄存器區(qū)域,以及相應(yīng)的讀寫函數(shù),vgic_v2_dist_registers 數(shù)組最終會提供給dispach_mmio_read/dispach_mmio_write 函數(shù)來查詢與調(diào)用;
- 當(dāng)Guest OS訪問
Distributor 時,觸發(fā)IO異常并切換回Host進(jìn)行處理,io_mem_abort 會根據(jù)總線的類型(MMIO)去查找到對應(yīng)的讀寫函數(shù)進(jìn)行操作,也就是圖中對應(yīng)的dispatch_mmio_read/dispach_mmio_write 函數(shù),最終完成寄存器區(qū)域的讀寫;
- 圖中的紅色線,代表的就是異常處理的執(zhí)行流,可以說是一目了然了。
耗時耗力耗心血的一篇文章終于寫完了,ARMv8 GICv2中斷虛擬化的總體框架和流程應(yīng)該算是理順了,全網(wǎng)相關(guān)主題的文章并不多,希望能給帶來點(diǎn)幫助吧。
如果對你有用的話,在看,分享,打賞三連吧。
參考
《arm_gic_architecture_specification》
《ARM_Interrupt_Virtualization》
《VM-Support-ARM》
《CoreLink GIC-400 Generic Interrupt Controller》
《Virtualization in the ARM Architecture》
https://git./pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=721eecbf4fe995ca94a9edec0c9843b1cc0eaaf3
|