ARMv8/v9 Generic Timer虛擬化架構(gòu)拆解做虛擬化平臺(tái)的老哥們應(yīng)該都有同感時(shí)間不對(duì)一切白給。無(wú)論是虛擬機(jī)的時(shí)鐘漂移、線程調(diào)度延遲還是容器網(wǎng)絡(luò)的超時(shí)重傳底層都是定時(shí)器在撐著。而ARM平臺(tái)上這個(gè)定時(shí)器地基就是Generic Timer。今天這篇不聊泛泛的架構(gòu)概念直接進(jìn)到ARMv8/v9 Generic Timer在虛擬化場(chǎng)景下的內(nèi)部機(jī)制從硬件視圖、軟件分層到KVM落地實(shí)現(xiàn)一整套拆開(kāi)揉碎講清楚。先說(shuō)清楚這文章解決什么問(wèn)題如果你正在做KVM虛擬化開(kāi)發(fā)、BSP適配、或者排查虛擬機(jī)時(shí)鐘異常類問(wèn)題這篇文章能幫你建立起從硬件定時(shí)器到KVM虛擬中斷的完整鏈路認(rèn)知。如果你只是聽(tīng)說(shuō)過(guò)Generic Timer想入門跟著走一遍也能搞清楚它的核心機(jī)制后面遇到問(wèn)題至少知道去哪一層排查。標(biāo)題里V-15和A-40是我們內(nèi)部項(xiàng)目對(duì)虛擬化和架構(gòu)兩塊內(nèi)容的編號(hào)不必糾結(jié)具體含義下面直接進(jìn)正題。1. 定時(shí)器虛擬化的三個(gè)核心難題1.1 時(shí)間在虛擬化世界里為什么這么難虛擬化最容易被低估的復(fù)雜度就是時(shí)間。CPU、內(nèi)存、設(shè)備都可以通過(guò)硬件虛擬化擴(kuò)展來(lái)加速唯獨(dú)時(shí)間這個(gè)東西它的設(shè)備是每顆CPU核心自帶的而且它的讀取頻率極高——操作系統(tǒng)的時(shí)鐘節(jié)拍、調(diào)度器的tick、協(xié)議棧的超時(shí)計(jì)算全都在高頻讀時(shí)間。想象一下你有一個(gè)物理鬧鐘現(xiàn)在要把它分給10個(gè)人用每個(gè)人都想在自己的時(shí)間線上設(shè)置鬧鈴、讀取當(dāng)前時(shí)間而且互相不能干擾。更麻煩的是每個(gè)人虛擬機(jī)還希望自己可以隨意撥快撥慢手表修改系統(tǒng)時(shí)間但不能影響別人。這就是定時(shí)器虛擬化的本質(zhì)難題。具體拆解成三個(gè)問(wèn)題來(lái)看時(shí)間來(lái)源一致性所有虛擬機(jī)看到的當(dāng)前時(shí)間必須有一個(gè)統(tǒng)一的基準(zhǔn)不能每顆CPU各說(shuō)各話否則遷移和多核場(chǎng)景直接崩。虛擬時(shí)間隔離每臺(tái)虛擬機(jī)需要自己的時(shí)間線這個(gè)時(shí)間線的起點(diǎn)可以不同比如虛擬機(jī)剛啟動(dòng)時(shí)時(shí)間是2010年宿主機(jī)已經(jīng)是2024年而且虛擬機(jī)修改自己的時(shí)間不能影響宿主機(jī)和其他虛擬機(jī)。定時(shí)中斷路由每臺(tái)虛擬機(jī)要能設(shè)置自己的鬧鐘時(shí)間到了要正確觸發(fā)對(duì)應(yīng)的虛擬中斷并且要精確到微秒級(jí)別不能靠軟件輪詢。這三個(gè)問(wèn)題ARM Generic Timer的虛擬化架構(gòu)就是專門為它們?cè)O(shè)計(jì)的。1.2 ARM沒(méi)有給定時(shí)器單獨(dú)開(kāi)一條虛擬化捷徑這里要說(shuō)一個(gè)容易誤解的點(diǎn)。ARM在虛擬化上做了很多硬件加速比如GIC (Generic Interrupt Controller) 對(duì)虛擬中斷的直接注入MMU有Stage-2地址轉(zhuǎn)換。但定時(shí)器這個(gè)模塊ARM并沒(méi)有提供一個(gè)虛擬定時(shí)器設(shè)備讓你直接操作。它采用的方式是提供一組精心設(shè)計(jì)的硬件機(jī)制讓Hypervisor用trap-and-emulate的方式來(lái)實(shí)現(xiàn)虛擬定時(shí)器但是把這個(gè)過(guò)程的開(kāi)銷壓縮到極低。為什么不像PCIe直通那樣直接把定時(shí)器直通給虛擬機(jī)因?yàn)槎〞r(shí)器不是獨(dú)立設(shè)備它是CPU核心的一部分而且多個(gè)虛擬機(jī)共享同一顆物理CPU。直通等于讓一個(gè)虛擬機(jī)霸占硬件資源其他虛擬機(jī)就沒(méi)法用定時(shí)器了。所以說(shuō)ARM Generic Timer的虛擬化架構(gòu)本質(zhì)上是一個(gè)硬件輔助的軟件虛擬化方案。理解這一點(diǎn)后面看KVM的代碼邏輯就會(huì)順很多。2. Generic Timer硬件機(jī)制全景拆解2.1 系統(tǒng)計(jì)數(shù)器整個(gè)時(shí)間世界的基準(zhǔn)ARM Generic Timer的頂層是一套系統(tǒng)級(jí)的計(jì)數(shù)器叫System Counter。這個(gè)計(jì)數(shù)器是唯一的、全局的、單調(diào)遞增的整個(gè)SoC上所有核心看到的值都是一樣的。它通常由主板上的晶振驅(qū)動(dòng)頻率一般在1MHz到50MHz之間。System Counter在軟件側(cè)體現(xiàn)為兩個(gè)寄存器視圖CNTPCT物理計(jì)數(shù)器和CNTVCT虛擬計(jì)數(shù)器。這兩個(gè)寄存器都是64位的單位是tick。但是注意ARM的spec規(guī)定軟件不能直接讀System Counter本身必須通過(guò)每個(gè)核心上的CNTPCT/CNTVCT寄存器來(lái)讀。為什么要區(qū)分物理和虛擬兩套計(jì)數(shù)器視圖答案很簡(jiǎn)單物理計(jì)數(shù)器給宿主機(jī)用虛擬計(jì)數(shù)器給虛擬機(jī)用。虛擬計(jì)數(shù)器 物理計(jì)數(shù)器 - Offset這個(gè)Offset由Hypervisor設(shè)置。這就是前面說(shuō)的虛擬時(shí)間線的實(shí)現(xiàn)基礎(chǔ)。2.2 每個(gè)核心上的定時(shí)器組件結(jié)構(gòu)每個(gè)ARM核心上有兩組重要的定時(shí)器組件一組是給非安全世界的一組是給安全世界的。我們做虛擬化主要關(guān)注非安全世界也就是EL1和EL2這兩層下面的結(jié)構(gòu)以這套為主。每個(gè)核心上有四種定時(shí)器物理定時(shí)器 (Physical Timer)通常用于EL1/EL0非安全世界中斷號(hào)是PPI 13。虛擬定時(shí)器 (Virtual Timer)通常用于給虛擬機(jī)提供定時(shí)中斷中斷號(hào)是PPI 14。EL2物理定時(shí)器 (EL2 Physical Timer)給Hypervisor自己用的定時(shí)器中斷是PPI 26。安全物理定時(shí)器 (Secure Physical Timer)給TrustZone安全世界用的虛擬化場(chǎng)景一般用不到。每一種定時(shí)器都有自己的一組寄存器CompareValue比較值、Control控制、Status狀態(tài)。定時(shí)器的原理很簡(jiǎn)單當(dāng)前計(jì)數(shù)值 CompareValue 的時(shí)候觸發(fā)一次中斷。2.3 關(guān)鍵寄存器與作用域劃分把寄存器按訪問(wèn)權(quán)限和虛擬化角色拆開(kāi)看落實(shí)到代碼和調(diào)試上會(huì)更有操作性寄存器訪問(wèn)層級(jí)虛擬化角色CNTPCT_EL0EL0/EL1可讀物理計(jì)數(shù)器Hypervisor讀物理時(shí)間用CNTVCT_EL0EL0/EL1可讀虛擬計(jì)數(shù)器虛擬機(jī)讀當(dāng)前時(shí)間CNTVOFF_EL2僅EL2可寫虛擬計(jì)數(shù)器偏移量虛擬機(jī)時(shí)間線原點(diǎn)CNTP_TVAL_EL0EL0/EL1可寫物理定時(shí)器的遞減計(jì)數(shù)值CNTP_CTL_EL0EL0/EL1可寫物理定時(shí)器控制使能、屏蔽、狀態(tài)CNTP_CVAL_EL0EL0/EL1可寫物理定時(shí)器比較值CNTV_TVAL_EL0EL0/EL1可寫虛擬定時(shí)器的遞減計(jì)數(shù)值CNTV_CTL_EL0EL0/EL1可寫虛擬定時(shí)器控制CNTV_CVAL_EL0EL0/EL1可寫虛擬定時(shí)器比較值CNTHP_TVAL_EL2僅EL2EL2物理定時(shí)器CNTHP_CTL_EL2僅EL2EL2物理定時(shí)器控制CNTHP_CVAL_EL2僅EL2EL2物理定時(shí)器比較值CNTHCTL_EL2僅EL2控制EL0對(duì)計(jì)數(shù)器和定時(shí)器的訪問(wèn)權(quán)限CNTKCTL_EL1EL1可寫控制EL0對(duì)內(nèi)核定時(shí)器寄存器的訪問(wèn)這張表建議存一下排問(wèn)題的時(shí)候會(huì)反復(fù)用到。特別是CNTVOFF_EL2和CNTHCTL_EL2這兩個(gè)是整個(gè)虛擬化的樞紐。2.4 計(jì)數(shù)器讀路徑為什么虛擬機(jī)讀時(shí)間也要被攔截這里有一個(gè)很多初學(xué)者沒(méi)注意到的設(shè)計(jì)點(diǎn)虛擬機(jī)執(zhí)行CNTVCT_EL0讀取時(shí)間在KVM的默認(rèn)配置下是不需要trap到EL2的。ARM通過(guò)硬件機(jī)制讓CNTVCT_EL0直接讀出來(lái)一個(gè)已經(jīng)減去了CNTVOFF_EL2的值整個(gè)過(guò)程發(fā)生在硬件層面虛擬機(jī)根本不知道偏移的存在。但是有一個(gè)例外當(dāng)虛擬機(jī)運(yùn)行在32位模式而Hypervisor需要讀取CNTPCT的時(shí)候情況就變得復(fù)雜了。32位guest訪問(wèn)CNTPCT會(huì)拆成兩次32位load高32位和低32位這中間可能發(fā)生高低位不一致的問(wèn)題。KVM內(nèi)核對(duì)這個(gè)問(wèn)題有專門的patch處理路徑后面在常見(jiàn)問(wèn)題部分會(huì)講到。3. KVM定時(shí)器虛擬化架構(gòu)設(shè)計(jì)3.1 分層模型Host Timer和Guest TimerKVM在arch/arm64/kvm/arch_timer.c中實(shí)現(xiàn)了完整的定時(shí)器虛擬化邏輯。整套設(shè)計(jì)圍繞兩條時(shí)間線展開(kāi)Host時(shí)間線基于CNTPCT物理計(jì)數(shù)器KVM用它來(lái)調(diào)度vCPU的執(zhí)行、計(jì)算虛擬機(jī)的運(yùn)行時(shí)間。Guest時(shí)間線基于CNTVCT虛擬計(jì)數(shù)器虛擬機(jī)里的操作系統(tǒng)看到的時(shí)間。兩條時(shí)間線之間的橋梁就是CNTVOFF_EL2。KVM在加載vCPU到物理CPU上的時(shí)候?qū)懭脒@個(gè)寄存器vCPU切走的時(shí)候不需要恢復(fù)因?yàn)橄聜€(gè)vCPU加載時(shí)會(huì)重新寫這個(gè)操作在關(guān)鍵路徑上只有一次MSR寫開(kāi)銷極低。定時(shí)器的虛擬化用到的核心結(jié)構(gòu)體在KVM中分成兩層struct arch_timer_cpu { struct arch_timer_context timers[NR_KTIMERS]; struct hrtimer hrtimer; bool is_timer_running; }; struct arch_timer_context { struct kvm_vcpu *vcpu; enum kvm_arch_timers timer; u64 cnt_cval; u64 cnt_ctl; bool loaded; bool ready; };第一層是per-CPU結(jié)構(gòu)的每個(gè)vCPU一組第二層是具體的物理定時(shí)器和虛擬定時(shí)器各自獨(dú)立的上下文。從結(jié)構(gòu)體上就能看出設(shè)計(jì)意圖物理和虛擬兩個(gè)定時(shí)器分別模擬各自維護(hù)比較值和控制位kvm根據(jù)guest的配置決定用哪個(gè)。3.2 Virtual Timer和Physical Timer的分工策略這是KVM定時(shí)器虛擬化設(shè)計(jì)里最精彩的部分。為什么要有兩套定時(shí)器給guest用表面上看有虛擬定時(shí)器就夠了guest設(shè)鬧鐘就用CNTV_CVAL_EL0時(shí)間到了觸發(fā)PPI 14中斷不就行了嗎真實(shí)原因是某些guest操作系統(tǒng)會(huì)直接操作物理定時(shí)器而不是虛擬定時(shí)器。比如Linux內(nèi)核早期的arch timer驅(qū)動(dòng)它在某些配置下直接使用物理timer。還有32位的ARM guest內(nèi)核某些版本的代碼路徑上會(huì)讀取CNTPCT來(lái)校準(zhǔn)時(shí)間。如果guest運(yùn)行在EL1虛擬機(jī)里它訪問(wèn)CNTP_TVAL_EL0和CNTP_CTL_EL0是會(huì)直接透過(guò)到硬件物理定時(shí)器的在trap沒(méi)有配置的情況下它會(huì)在沒(méi)有Hypervisor掌控的情況下直接產(chǎn)生物理中斷這個(gè)中斷會(huì)直接送進(jìn)guest卻沒(méi)有任何虛擬化層的管理成為一顆無(wú)法關(guān)閉的定時(shí)炸彈。所以KVM的做法是分兩層guest的物理定時(shí)器和虛擬定時(shí)器操作都必須經(jīng)過(guò)KVM的接管和控制。它最終映射到Host側(cè)的實(shí)現(xiàn)是用Host的一個(gè)真正的物理定時(shí)器來(lái)backing guest的某個(gè)定時(shí)器再通過(guò)vGIC把中斷以虛擬中斷的形式注入回guest。具體到實(shí)現(xiàn)上KVM的策略是虛擬定時(shí)器用虛擬計(jì)數(shù)器CNTVCT作為時(shí)間基準(zhǔn)backing hrtimer基于host的CLOCK_MONOTONIC實(shí)際讀取cntpct換算中斷走PPI 14通過(guò)vgic注入。物理定時(shí)器用物理計(jì)數(shù)器CNTPCT作為時(shí)間基準(zhǔn)backing hrtimer同樣基于host時(shí)間中斷走PPI 13通過(guò)vgic注入。兩個(gè)timer的backing hrtimer在host上共用同一個(gè)hrtimer實(shí)體arch_timer_cpu-hrtimer通過(guò)hrtimer_start重新指定到期時(shí)間來(lái)實(shí)現(xiàn)兩個(gè)timer的切換和共享。3.3 中斷的虛擬化路徑從硬件中斷到Guest IRQ定時(shí)器中斷是整個(gè)虛擬化鏈路里最長(zhǎng)的路徑之一值得完整走一遍Host物理定時(shí)器超時(shí)觸發(fā)host的timer中斷handler。KVM的timer handlerkvm_timer_irq_handler被調(diào)用。這個(gè)handler識(shí)別中斷來(lái)源是backing timer到期。KVM檢查對(duì)應(yīng)的arch_timer_context確認(rèn)是否應(yīng)該向guest注入中斷。如果要注入調(diào)用kvm_timer_update_irq通過(guò)irqchipvgic設(shè)置對(duì)應(yīng)的虛擬中斷為pending狀態(tài)。vCPU在下一次進(jìn)入guest模式時(shí)vgic會(huì)把pending中斷通過(guò)list register注入guest在EL1收到中斷。這里面有一個(gè)容易被忽略的關(guān)鍵細(xì)節(jié)KVM在判斷是否應(yīng)該向guest注入中斷的時(shí)候不是簡(jiǎn)單看hrtimer到期就注入而是要對(duì)比當(dāng)前的虛擬計(jì)數(shù)器值和guest設(shè)置的定時(shí)器比較值。因?yàn)閔rtimer的精度和實(shí)際timer的精度存在微小偏差KVM需要做一次校準(zhǔn)static bool kvm_timer_irq_can_fire(struct arch_timer_context *timer_ctx) { u64 cnt; u64 cval, ctl; cval timer_ctx-cnt_cval; ctl timer_ctx-cnt_ctl; if (kvm_timer_should_fire(timer_ctx)) return false; cnt kvm_phys_timer_read(); if (cnt cval) return false; return (ctl ARCH_TIMER_CTRL_ENABLE) !(ctl ARCH_TIMER_CTRL_IT_MASK); }注意最后兩個(gè)條件ENABLE位和IT_MASK位。這說(shuō)明KVM嚴(yán)格遵循ARM定時(shí)器的硬件語(yǔ)義即使hrtimer到點(diǎn)了如果guest屏蔽了中斷或者禁用了定時(shí)器也不能硬注入。3.4 KVM如何處理Guest屏蔽定時(shí)器中斷這個(gè)場(chǎng)景在真實(shí)運(yùn)行中經(jīng)常出現(xiàn)而且坑特別多。Guest的Linux內(nèi)核在處理定時(shí)器中斷時(shí)會(huì)先屏蔽中斷設(shè)置IMASK位清掉pending狀態(tài)處理完再重新使能。如果KVM在guest屏蔽中斷期間直接把hrtimer停了guest重新使能時(shí)會(huì)發(fā)現(xiàn)定時(shí)器已經(jīng)沒(méi)有在走時(shí)間直接卡住。KVM的處理方式是即使guest屏蔽了中斷hrtimer也要繼續(xù)跑因?yàn)閔rtimer的到期只是一個(gè)信號(hào)真正的是否注入中斷還要看guest的屏蔽狀態(tài)。而且KVM在hrtimer到期時(shí)如果發(fā)現(xiàn)guest屏蔽了中斷會(huì)通過(guò)編程硬件定時(shí)器的比較值讓它在下一個(gè)預(yù)期的到期點(diǎn)再次觸發(fā)形成輪詢等待的效果。這個(gè)繼續(xù)跑、不注入的策略保證了guest重新使能定時(shí)器后馬上就能收到一個(gè)pending的中斷時(shí)間線不會(huì)斷。但是代價(jià)是host側(cè)會(huì)多次觸發(fā)定時(shí)器中斷增加一定的CPU開(kāi)銷。這塊在性能敏感場(chǎng)景值得做profile看看是不是有大量的spurious wakeup。4. 定時(shí)器的生命周期管理與vCPU調(diào)度聯(lián)動(dòng)4.1 vCPU加載與卸載時(shí)定時(shí)器狀態(tài)保存KVM在vCPU切入和切出時(shí)對(duì)定時(shí)器有明確的狀態(tài)管理。切出的場(chǎng)景是vCPU被搶占、運(yùn)行時(shí)間片到期或者需要退出到用戶空間處理IO。切入的時(shí)候KVM做這么幾件事void kvm_timer_vcpu_load(struct kvm_vcpu *vcpu) { struct arch_timer_cpu *timer vcpu_to_timer(vcpu); struct arch_timer_context *vtimer vcpu_vtimer(vcpu); struct arch_timer_context *ptimer vcpu_ptimer(vcpu); kvm_timer_update_state(vcpu); if (timer-is_timer_running) return; timer-is_timer_running true; /* Set the offset for the virtual timer */ timer_set_voffset(vcpu-kvm, vcpu-arch.timer_irq.offset); kvm_timer_vcpu_load_nogic(vcpu); kvm_timer_unblock(vcpu); }關(guān)鍵在于寫入CNTVOFF_EL2把這條vCPU的虛擬時(shí)間線切到自己的坐標(biāo)。更新vtimer和ptimer的硬件寄存器讓guest看到的定時(shí)器狀態(tài)連續(xù)。如果backing hrtimer已經(jīng)啟動(dòng)過(guò)切回來(lái)時(shí)不需要重新啟動(dòng)hrtimer它一直在跑只是到期事件可能因?yàn)関CPU不在而錯(cuò)過(guò)了。這里有一個(gè)補(bǔ)課機(jī)制后面講。切出的時(shí)候邏輯對(duì)稱但要額外注意void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu) { struct arch_timer_cpu *timer vcpu_to_timer(vcpu); struct arch_timer_context *vtimer vcpu_vtimer(vcpu); /* If the timer has expired, inject the interrupt */ if (kvm_timer_should_fire(vtimer)) kvm_timer_update_irq(vcpu, true, vtimer); if (!timer-is_timer_running) return; timer-is_timer_running false; timer_save_state(vcpu); timer-hrtimer.cancel(cancel_phys_timer); }這里有一個(gè)設(shè)計(jì)亮點(diǎn)即使vCPU被切出hrtimer也不是被cancel掉取消而是保留。如果guest設(shè)置的定時(shí)器到期時(shí)間還沒(méi)到hrtimer留在host的timer wheel里到期時(shí)照樣觸發(fā)如果guest設(shè)置的到期時(shí)間已經(jīng)過(guò)了那么在切出的時(shí)候KVM會(huì)立刻把虛擬中斷的pending狀態(tài)置上等vCPU下一次進(jìn)入時(shí)直接處理。這就是為什么虛擬機(jī)的定時(shí)器即使在高負(fù)載宿主上也不會(huì)出現(xiàn)明顯漂移——因?yàn)镵VM用的是host的硬件定時(shí)器來(lái)保證到期精度而不是依賴vCPU的調(diào)度。4.2 補(bǔ)課機(jī)制Guest錯(cuò)過(guò)定時(shí)器中斷怎么辦展開(kāi)講一下上面提到的補(bǔ)課機(jī)制。場(chǎng)景是這樣的guest的定時(shí)器在10ms后到期但是host負(fù)載很高vCPU在8ms的時(shí)候被切出了物理CPU直到20ms后才重新被調(diào)度回來(lái)。如果沒(méi)有補(bǔ)課機(jī)制這10ms的定時(shí)器事件就丟了guest醒來(lái)后發(fā)現(xiàn)時(shí)間已經(jīng)過(guò)去了20ms但它的定時(shí)器中斷一個(gè)都沒(méi)收到所有依賴定時(shí)器的邏輯全都錯(cuò)亂。KVM的補(bǔ)課邏輯在kvm_timer_vcpu_load里static void kvm_timer_update_state(struct kvm_vcpu *vcpu) { struct arch_timer_cpu *timer vcpu_to_timer(vcpu); struct arch_timer_context *vtimer vcpu_vtimer(vcpu); struct arch_timer_context *ptimer vcpu_ptimer(vcpu); if (kvm_timer_should_fire(vtimer) ! vtimer-irq.level) kvm_timer_update_irq(vcpu, !vtimer-irq.level, vtimer); if (kvm_timer_should_fire(ptimer) ! ptimer-irq.level) kvm_timer_update_irq(vcpu, !ptimer-irq.level, ptimer); timer-hrtimer_active false; }kvm_timer_should_fire會(huì)做一次當(dāng)前虛擬計(jì)數(shù)器和比較值的大小判斷。如果vCPU回來(lái)時(shí)發(fā)現(xiàn)當(dāng)前時(shí)間已經(jīng)超過(guò)了guest設(shè)置的值就把中斷狀態(tài)更新為pending。因?yàn)檫@段時(shí)間guest的定時(shí)器中斷本質(zhì)上一直在pendingKVM通過(guò)這此判斷來(lái)模擬這個(gè)狀態(tài)。這個(gè)機(jī)制背后反映的設(shè)計(jì)哲學(xué)是定時(shí)器中斷本質(zhì)上是一個(gè)事件攜帶的機(jī)制只要最終狀態(tài)正確中間的丟失可以用狀態(tài)同步來(lái)彌補(bǔ)不需要逐個(gè)事件追溯。這與中斷控制器虛擬化中l(wèi)evel trigger的處理思路一脈相承。4.3 32位Guest的特殊處理與CNTPCT陷阱談32位guest之前先解釋一下為什么會(huì)有trap問(wèn)題。當(dāng)虛擬機(jī)運(yùn)行在32位模式AArch32ARM架構(gòu)規(guī)定訪問(wèn)某些64位寄存器的行為會(huì)primary變化。比如32位guest訪問(wèn)CNTPCT_EL0會(huì)被trap到EL2。為什么因?yàn)?2位guest無(wú)法一次完成64位load只能拆成兩次32位load兩次之間的高32位值可能已經(jīng)變了。如果不做trap處理guest會(huì)讀到撕裂的時(shí)間值。KVM的處理是接受這個(gè)trap然后模擬讀取用一次原子的64位讀拿到CNTPCT再拆成高32位和低32位返回給guest。所以這里多出來(lái)的開(kāi)銷是必然的不是KVM實(shí)現(xiàn)的問(wèn)題。但這里有一個(gè)嚴(yán)重的性能隱患如果guest的Linux內(nèi)核在時(shí)鐘校準(zhǔn)里頻繁讀CNTPCT每次都會(huì)有trap整個(gè)系統(tǒng)時(shí)間校準(zhǔn)路徑會(huì)變得特別慢。實(shí)際的KVM在arch/arm64/kvm/hyp/hyp-entry.S中有對(duì)應(yīng)的handlertableel0_32_pc: ... el0_32_cntpct: ...它做了這樣的處理在hyp階段直接讀出CNTPCT拆成兩個(gè)32位值設(shè)置好返回寄存器后直接eret回guest全程不退出到host kernel。這個(gè)路徑把多次trap的開(kāi)銷降到了單次trap一次內(nèi)存讀算是在架構(gòu)限制下的最優(yōu)解。我記得還有一處是CNTVCT的訪問(wèn)在ARMv8.0的某個(gè)勘誤表里有提到32位guest讀CNTVCT_EL0也可能產(chǎn)生詭異的撕裂值個(gè)別內(nèi)核版本會(huì)在head.S里做一次重讀校準(zhǔn)這里就不再展開(kāi)了。5. KVM定時(shí)器實(shí)驗(yàn)復(fù)現(xiàn)搭建一個(gè)最小觀測(cè)環(huán)境5.1 環(huán)境準(zhǔn)備與內(nèi)核配置要點(diǎn)紙上談兵沒(méi)用。我自己的調(diào)試環(huán)境是QEMU KVM跑ARM64 guesthost是樹(shù)莓派的Ubuntu Server內(nèi)核5.15和另外一臺(tái)鯤鵬920服務(wù)器兩邊邏輯一致只是性能差很多。要復(fù)現(xiàn)本文講的定時(shí)器虛擬化行為需要確認(rèn)以下配置項(xiàng)CONFIG_KVMyCONFIG_KVM_ARM_HOSTy這個(gè)不用多說(shuō)。CONFIG_ARM_ARCH_TIMERyARM的arch timer驅(qū)動(dòng)。CONFIG_ARM_GIC_V3y中斷控制器的v3版本。CONFIG_HZ_250或者CONFIG_HZ_1000guest里配置的時(shí)鐘頻率會(huì)影響定時(shí)器中斷頻率方便觀察差異。調(diào)試輸出方面建議打開(kāi)tracefs的timer相關(guān)事件mount -t tracefs tracefs /sys/kernel/tracing echo 1 /sys/kernel/tracing/events/kvm/kvm_timer_update_irq/enable echo 1 /sys/kernel/tracing/events/kvm/kvm_hrtimer_start/enable echo 1 /sys/kernel/tracing/events/kvm/kvm_hrtimer_cancel/enable cat /sys/kernel/tracing/trace_pipe這三個(gè)trace event能完整還原KVM定時(shí)器的生命周期全貌從hrtimer啟動(dòng)到中斷注入全鏈路可見(jiàn)。實(shí)測(cè)里面kvm_timer_update_irq的觸發(fā)頻率和guest的HZ配置強(qiáng)相關(guān)可以直觀看到虛擬定時(shí)器的tick節(jié)奏。5.2 一個(gè)觀測(cè)腳本確認(rèn)CNTVOFF在不同VM間隔離要驗(yàn)證CNTVOFF_EL2確實(shí)起到了虛擬機(jī)時(shí)間隔離的作用可以這樣操作在宿主機(jī)寫一個(gè)內(nèi)核模塊讀取CNTVCT_EL0和CNTPCT_EL0的差值不過(guò)這需要root權(quán)限和內(nèi)核模塊不是每個(gè)環(huán)境都方便更輕量的方式是跑一個(gè)只讀虛擬計(jì)數(shù)器的小程序#include stdint.h #include stdio.h #include time.h static inline uint64_t cntvct_read(void) { uint64_t val; asm volatile(mrs %0, cntvct_el0 : r (val)); return val; } static inline uint64_t cntpct_read(void) { uint64_t val; asm volatile(mrs %0, cntpct_el0 : r (val)); return val; } int main(void) { struct timespec ts; clock_gettime(CLOCK_MONOTONIC, ts); uint64_t v cntvct_read(); uint64_t p cntpct_read(); printf(CNTVCT%lu CNTPCT%lu diff%ld tick\n, v, p, p - v); return 0; }在宿主機(jī)上編譯運(yùn)行diff會(huì)是一個(gè)固定值0或者某個(gè)常數(shù)取決于kernel啟動(dòng)時(shí)是否設(shè)置了CNTVOFF為0在虛擬機(jī)里編譯運(yùn)行同一個(gè)程序diff就是KVM設(shè)置的CNTVOFF_EL2值。兩個(gè)VM看到的diff不同這就能非常直觀地驗(yàn)證虛擬時(shí)間線的隔離。實(shí)測(cè)中diff值通常是一個(gè)非常大的隨機(jī)偏移這就是KVM為每個(gè)VM分配的獨(dú)立時(shí)間原點(diǎn)。5.3 用ftrace驗(yàn)證hrtimer與注入的因果關(guān)系更深入地驗(yàn)證中斷注入路徑可以同時(shí)打開(kāi)kvm和timer的trace事件echo 1 /sys/kernel/tracing/events/kvm/enable echo 1 /sys/kernel/tracing/events/timer/enable cat /sys/kernel/tracing/trace在guest里跑一個(gè)高頻率的定時(shí)器程序比如nanosleep 1msguest產(chǎn)生的定時(shí)器中斷會(huì)導(dǎo)致host側(cè)對(duì)應(yīng)的backing hrtimer反復(fù)到期。trace里可以看到hrtimer_expire_entry到kvm_timer_update_irq之間通常只有幾微秒的延遲這說(shuō)明中斷注入路徑是硬實(shí)時(shí)鏈路沒(méi)有經(jīng)過(guò)workqueue之類的延遲機(jī)制。如果發(fā)現(xiàn)hrtimer到期到中斷注入之間出現(xiàn)了超過(guò)100微秒的間隔那就要懷疑是不是host上有其他高優(yōu)先級(jí)中斷搶占了CPU或者vCPU沒(méi)有在物理CPU上運(yùn)行導(dǎo)致hrtimer回調(diào)無(wú)法及時(shí)執(zhí)行。這個(gè)時(shí)候要改成per-cpu的hrtimerHRTIMER_MODE_ABS_HARD來(lái)保證硬中斷上下文中處理后面調(diào)優(yōu)部分會(huì)講怎么改。6. 高頻問(wèn)題排查與性能調(diào)優(yōu)實(shí)錄6.1 虛擬機(jī)時(shí)鐘漂移最快排查清單虛擬機(jī)上最常被人吐槽的問(wèn)題就是時(shí)鐘漂移本來(lái)以為是網(wǎng)絡(luò)問(wèn)題查半天發(fā)現(xiàn)是時(shí)間不對(duì)導(dǎo)致TCP時(shí)間戳錯(cuò)亂。遇到時(shí)鐘漂移按以下順序排查現(xiàn)象可能原因排查方法guest時(shí)間比host慢CNTVOFF配置異常host讀CNTVCT與guest讀CNTVCT對(duì)比guest時(shí)間跳變遷移后CNTVOFF未正確恢復(fù)檢查migration代碼路徑確認(rèn)寫入CNTVOFF_EL2guest時(shí)間完全不動(dòng)CNTFRQ未設(shè)置或異常dmesg看arch_timer驅(qū)動(dòng)初始化日志定時(shí)中斷抖動(dòng)大hrtimer模式不是HARD查/sys/kernel/debug/tracing看hrtimer回調(diào)上下文32位guest時(shí)間異常CNTPCT trap路徑問(wèn)題strace guest內(nèi)讀時(shí)間函數(shù)看是否有頻繁trap最坑的一次經(jīng)歷是某個(gè)guest內(nèi)核版本里CNTKCTL_EL1的配置有bug導(dǎo)致guest無(wú)法在EL0訪問(wèn)CNTVCT_EL0結(jié)果guest的vDSO里的時(shí)鐘讀取全部走了系統(tǒng)調(diào)用性能掉了一個(gè)量級(jí)。這種問(wèn)題靠監(jiān)測(cè)是看不出來(lái)的要學(xué)會(huì)用perf trace去看guest內(nèi)時(shí)間系統(tǒng)調(diào)用的頻率是否異常。6.2 中斷風(fēng)暴問(wèn)題hrtimer空轉(zhuǎn)與RESCHED經(jīng)常有老哥反饋宿主機(jī)負(fù)載不高但CPU0的中斷占用率很高irqtop里看arch_timer中斷每秒觸發(fā)幾萬(wàn)次。大概率是guest里的定時(shí)器配置了過(guò)高的頻率比如1000Hz而且guest處于idle狀態(tài)不斷進(jìn)入WFI。KVM對(duì)guest的WFI處理會(huì)直接退出到host讓vCPU線程睡在hrtimer上等到下次虛擬定時(shí)器到期再喚醒。如果guest設(shè)置了非常短的定時(shí)器間隔vCPU就會(huì)不停地醒來(lái)再睡每次醒來(lái)都要走一遍完整的vCPU加載流程開(kāi)銷非常大。調(diào)優(yōu)方向有兩個(gè)在guest里調(diào)低HZ從1000降到250能減少3/4的中斷觸發(fā)頻率絕大多數(shù)服務(wù)器場(chǎng)景完全夠用。在host側(cè)確認(rèn)hrtimer的HRTIMER_MODE_ABS_HARD配置是否正確。KVM默認(rèn)對(duì)timer hrtimer用的是hard模式在硬中斷上下文執(zhí)行hrtimer回調(diào)如果降級(jí)成了soft模式回調(diào)會(huì)進(jìn)softirq延遲會(huì)明顯增加。同時(shí)要檢查KVM是否開(kāi)啟了irqchip in-kernel模式。如果使用userspace irqchip比如老的kvmtool或者某些嵌入式場(chǎng)景虛擬中斷要通過(guò)eventfd通知到用戶空間再寫回每次注入都是兩次ioctl的開(kāi)銷性能會(huì)差幾十倍。6.3 遷移場(chǎng)景下的定時(shí)器連續(xù)性保障vCPU熱遷移時(shí)定時(shí)器狀態(tài)遷移是一塊特別容易出bug的地方。KVM的遷移相關(guān)代碼在arch/arm64/kvm/arch_timer.c里有如下關(guān)鍵函數(shù)int kvm_timer_get_state(struct kvm_vcpu *vcpu) int kvm_timer_set_state(struct kvm_vcpu *vcpu)這兩個(gè)函數(shù)負(fù)責(zé)把當(dāng)前vCPU的定時(shí)器狀態(tài)比較值、控制位保存到kvm_timer_context里然后在目標(biāo)機(jī)上恢復(fù)。正常情況下遷移流程是源端暫停vCPU。kvm_timer_get_state保存vtimer和ptimer的cnt_cval、cnt_ctl。用戶空間QEMU/kvmtool把這些狀態(tài)傳給目標(biāo)端。目標(biāo)端kvm_timer_set_state恢復(fù)這些狀態(tài)。目標(biāo)端vCPU啟動(dòng)后在kvm_timer_vcpu_load時(shí)把cval寫入硬件寄存器。這里的坑在于目標(biāo)機(jī)的CNTVCT值和源機(jī)的CNTVCT值不一樣因?yàn)閮膳_(tái)機(jī)器的CNTVOFF_EL2不同。恢復(fù)狀態(tài)時(shí)必須把源機(jī)的cval換算成目標(biāo)機(jī)的cval換算公式是new_cval old_cval (new_vo - old_vo)。KVM在kvm_timer_set_state里會(huì)調(diào)用timer_set_voffset重新設(shè)置新VM的偏移然后根據(jù)偏移差調(diào)整cval。如果這一步做錯(cuò)了guest遷移后定時(shí)器要么立即觸發(fā)一次虛假中斷要么延后好久才觸發(fā)。調(diào)試這個(gè)問(wèn)題的辦法是在遷移前后各打印一下kvm_timer_get_state和kvm_timer_set_state出的cval和offsetecho 1 /sys/kernel/tracing/events/kvm/kvm_timer_get_state/enable echo 1 /sys/kernel/tracing/events/kvm/kvm_timer_set_state/enable對(duì)比兩份日志里的cnt_cval差值應(yīng)該和兩邊的CNTVOFF差值完全一致如果不一致就是換算邏輯出了問(wèn)題。6.4 從KVM向pKVM/槍口式虛擬化演進(jìn)的影響ARMv9開(kāi)始力推的CCAConfidential Compute Architecture和pKVMprotected KVM對(duì)定時(shí)器虛擬化的架構(gòu)影響值得提前關(guān)注。pKVM里Hypervisor本身被拆成了兩個(gè)世界root world高特權(quán)控制所有硬件和protected world受限的VMM運(yùn)行環(huán)境。這意味著原來(lái)運(yùn)行在EL2的KVM代碼被一分為二其中一部分降級(jí)到EL1。定時(shí)器虛擬化里最重要的CNTVOFF_EL2寫入操作在pKVM下由root world完成protected world的VMM不能再直接操作這個(gè)寄存器。整個(gè)中斷注入路徑也變了定時(shí)器中斷需要經(jīng)過(guò)root world的中轉(zhuǎn)才能到達(dá)protected world的VMM再到guest。這對(duì)系統(tǒng)軟件開(kāi)發(fā)者意味著什么以前在KVM里直接操作timer寄存器做優(yōu)化的代碼路徑需要重新審視。比如原來(lái)用戶態(tài)通過(guò)KVM_CAP_ARM_TIMER控制定時(shí)器行為的方式在pKVM里可能不再可用因?yàn)槟莻€(gè)狀態(tài)不在protected world的掌控范圍內(nèi)。好在ARM在硬件層面考慮了這一點(diǎn)EL2物理定時(shí)器PPI 26就是給hypervisor自己用的它不參與guest的定時(shí)器虛擬化所以hypervisor可以在不干擾guest虛擬定時(shí)器的情況下做自己的調(diào)度計(jì)時(shí)。pKVM也延續(xù)了這套設(shè)計(jì)用EL2物理定時(shí)器做自己的時(shí)間基準(zhǔn)不和guest的時(shí)間線混在一起。7. 寫在最后的個(gè)人經(jīng)驗(yàn)定時(shí)器虛擬化這塊看起來(lái)只是虛擬化體系里的一小塊但它牽扯到硬件架構(gòu)、中斷子系統(tǒng)、調(diào)度器、遷移等多個(gè)方向的交叉知識(shí)。串起來(lái)理解之后再去看其他設(shè)備的虛擬化比如vgic中斷虛擬化、PMU虛擬化很多設(shè)計(jì)思路都是相通的。我個(gè)人在做這套東西的過(guò)程中的幾個(gè)體會(huì)第一別上來(lái)就看KVM源碼先把ARM ARMARM Architecture Reference Manual里Generic Timer那章過(guò)一遍。很多KVM代碼里的常量和不直觀的位操作都是直接從寄存器語(yǔ)義翻譯過(guò)來(lái)的。第二排查時(shí)間相關(guān)問(wèn)題的時(shí)候建立時(shí)間線世界觀特別有用。時(shí)刻問(wèn)自己我現(xiàn)在看的是host時(shí)間線還是guest時(shí)間線CNTVOFF在中間扮演了什么角色一旦把坐標(biāo)系分清楚至少70%的問(wèn)題都能定位到正確方向。第三性能調(diào)優(yōu)不要憑空想。裝好ftrace和perf實(shí)測(cè)幾組數(shù)據(jù)再動(dòng)代碼。很多時(shí)候你以為瓶頸在中斷注入的路徑上實(shí)際測(cè)出來(lái)的結(jié)果可能完全相反。沒(méi)有測(cè)量就沒(méi)有優(yōu)化。最后說(shuō)一個(gè)調(diào)試小技巧如果你需要快速確認(rèn)一個(gè)guest當(dāng)前用的是vtimer還是ptimer只需要在guest里執(zhí)行cat /proc/interrupts | grep -E arch_timer|timer看中斷號(hào)。如果你看到的是一個(gè)外設(shè)中斷號(hào)非13/14說(shuō)明guest代碼里做了自定義處理這時(shí)候就要懷疑它是不是在EL1直接操作物理定時(shí)器繞過(guò)KVM的虛擬化了。這種情況在改裝過(guò)內(nèi)核的安卓環(huán)境里尤其常見(jiàn)值得多留個(gè)心眼。