前言

RT????? RealTime實時調度

CPU?單處理器芯片

pcpu????單處理器芯片中的一個核。

vcpu??? Xen的基本調度單位，可理解為進程。

預算??? Xen的RT調度中預算指的是任務的剩余運行時間

文檔所分析代碼為Xen4.11版本。

經過編寫過程中的反復查看，發現本文易讀性較差，因此引入彩色字體，

淡灰色字體表示與主題相關性不大；

紅色字體表示重要信息；

紫色字體是為了提神；

各色字體交織使用表示同色字體的連續性。

認真講，我并不十分看好Xen on arm的發展(代碼量不小、前有seL4，后有Ziron)，但是不得不說他是目前我們唯一可獲得、可用的arm端支持虛擬化的微內核，所有微內核都是有其共同點的，即保留最核心內核功能(其實我認為應該做出某種權衡，在微內核、宏內核之間，是否可以進行更細的分割，以平衡生態、代碼量、可移植性)。于是其他基于微內核的虛擬化實現，必然會走與Xen相似、甚至相同的路，如果能有其他更優秀的實現路線：比如不再依賴Domain0、更靈活的硬件外設驅動方案，也是會與Xen的思想有著千絲萬縷的聯系(就像Xen與Linux很多思想是一致的。于是我認為對Xen的解析，對HYP微內核的深刻理解，是可以為在微內核上的進一步發展提供靈感的，Xen當然是并不完善的，但是其優秀的成分必然也不少(不然誰會為止貢獻代碼呢)，你可以肆意的優化甚至大規模改變流程，但是對于一個微內核虛擬化方案，所有Xen需要支持的東西，我們肯定是無法錯過的；于是作為一個切入點，Xen是值得的。

?

目錄

前言

從核心的啟動函數start_xen()說起

在start_xen()

軟中斷softirq執行路線

軟定時器機制struct timers和struct timer

總結

一次調度的處理

在schedule()

描述Xen的調度單位vcpu

Xen向GuestOS伸出了魔爪

小結

RT調度的do_schedule()

RT調度的預算補充

RT調度的喚醒

RT調度的優先級

RT調度的數據結構

RT調度的deadline

小結

進一步

?

從核心的啟動函數start_xen()說起

調度時內核最核心功能之一，從內核啟動開始就會對啟動調度做準備，于是分析Xen內核啟動過程中對調度的預初始化和初始化，是分析調度的初始步驟。Xen內核啟動，會執行start_xen()過程，start_xen()是Xen微內核C代碼的入口。

在start_xen()

1.??setup_cache();

微內核會檢查cache屬性(略)；

2.??percpu_init_areas();

為每個pcpu分配空間，因為很多數據各pcpu都會有，比如cpu的頻率、id等[1]。此空間用于存放各pcpu自有數據，避免各個pcpu競爭使用造成饑餓，一般稱這種變量為per-cpu變量。[1]

3.??set_processor_id(0);

Xen微內核啟動首先會在第一個pcpu上執行，并設置所在的pcpu的id。[2]

4.??set_current((structvcpu *)0xfffff000); idle_vcpu[3][0]=?current[4];

現在代碼處于Xen微內核啟動的第一個執行vcpu?[5]，其他的pcpu并未啟動，最終，本vcpu會退化成為一個idle_vcpu?[6]。

5.??setup_virtual_regions(NULL,NULL);

略。

6.??init_traps();

運行在Xen上的GuestOS(包含特權域)都會認為自己擁有整個硬件[7]，于是所有的GuestOS都會嘗試執行所有計算指令(包括特權指令)，而這就是CPU對虛擬化支持的意義所在(指令被分為EL0-EL3(aarch64)特權等級)，每一個特權指令都不會被隨意執行，當運行在Xen之上的GuestOS在硬件執行了EL2級特權指令(GuestOS內核才被允許在EL1執行)，EL2特權指令將會產生異常，被Xen捕獲，init_traps()就是在初始化捕獲器，包含關鍵的CP15 CR12中HVBAR[8]等。這也是ARM架構規定特權指令等級的實施方式。

7.??smp_clear_cpu_maps();

Xen要根據設備樹進行初始化設置，清除CPU位圖后，將當前CPU0設入位圖。

8.??device_tree_flattened=early_fdt_map(fdt_paddr);

fdt_paddr在啟動start_xen()時傳入，是設備樹的起始地址；FDT(flatted device tree)的DTB存放有板級設備信息，大小不超過2M，最少8byte對齊，early_fdt_map()會對DTB合法性進行檢查，并創建對內存的映射[9]，device_tree_flattened應該是指向DTB所在內存起始地址。

9.??其他初始化

Xen在隨后根據DTB信息進行了大量初始化，設置啟動地址、設置頁表、根據平臺初始化ACPI(Advanced Configuration and Power Management Interface)的AP、完成內存初始化，這些操作與Xen調度分析關系不大，此處均不詳述(主要是有些東西弄清楚耗時太長)。

10.?system_state=SYS_STATE_boot；

system_state全局變量標志的Xen當前的狀態[10]。當前，Xen完成了內存子系統的初始化，從early_boot進入boot狀態。

11.?vm_init();

虛擬內存管理的初始化。

12.?init_IRQ();

各個中斷TYPE的初始化為IRQ_TYPE_INVALID(即IRQ正在初始化)[11]。

13.?platform_init();

根據硬件平臺的初始化，有廠商編寫并根據Xen的接口封裝，Xen會根據DTB信息進行匹配，得到可用的硬件平臺接口，并調用接口初始化函數。[12]

14.?對定時器、中斷控制器GIC、串口輸出、各pcpu預初始化。

preinit_xen_time();??初始化啟動所在CPU的定時器[13]，查找定時器在DTB的節點，設置設備節點的使用者為DOMID_XEN[14]；調用平臺接口初始化此定時器，記錄啟動時間[15]。

gic_preinit();???????初始化中斷控制器節點。[16]

串口初始化???????初始化UART設備、串口輸出的中斷、申請串口環形緩沖區。

CPU初始化???????檢測各pcpu可用性、一般屬性，初始化CPU位圖，更新nr_cpu_ids(保存有pcpu數)。

15.?init_xen_time();

獲得定時器中斷資源，放入timer_irq數組。

16.?gic_init();

GIC私有structgic_hw_operations * gic_hw_ops是GIC設備接口入口，此處調用其init()接口對GIC設備初始化。

17.?tasklet_subsys_init();

對tasklet機制[17]進行初始化，對各pcpu創建tasklet_list和softirq_tasklet_list；注冊一個CPU的Notifiter[18]；打開TASKLET_SOFTIRQ，并設定tasklet_softirq_action()為軟中斷處理函數。tasklet_softirq_action()調用do_tasklet_work()將struct tasklet從原有鏈表摘下并執行其內部提供的處理函數；執行完成后，若struct tasklet->scheduled_on[19]>=0則調用tasklet_enqueue()。tasklet_enqueue()會根據struct tasklet->is_softirq[20]決定將tasklet加入指定pcpu的softirq_tasklet_list[21]或tasklet_list[22]，softirq_tasklet_list將會在軟中斷執行，tasklet_list則會置位對應pcpu的tasklet_work_to_do變量的_TASKLET_enqueued位[23]。

18.?xsm_dt_init();

Xen Security Modules。Xen限制Domain的安全訪問控制機制，可以定義域間、域與HYP以及相關內存、設備資源的通訊、使用。類SELinux。

19.?init_timer_interrupt();

通過request_irq()，將timer_irq定時器中斷資源與處理函數timer_interrupt()連接。[24]

20.?timer_init();

執行open_softirq(TIMER_SOFTIRQ,timer_softirq_action)，將TIMER_SOFTIRQ[25]打開，并設置處理函數為timer_softirq_action()。timer_softirq_action()主要將當前pcpu的structtimer中的function執行。

21.?init_idle_domain();

執行open_softirq(SCHEDULE_SOFTIRQ,schedule)，將SCHEDULE_SOFTIRQ軟中斷打開并將schedule()調度函數給入；將所用調度器給入全局struct scheduler ops，然后執行cpu_schedule_up()，其中init_timer()將s_timer_fn()設入當前pcpu的struct schedule_data –> struct timer –>function中，s_timer_fn()會raise_softirq(SCHEDULE_SOFTIRQ)啟動調度。最后init_idle_domain創建了一個空閑域。

22.?其他初始化操作

start_xen()隨后對RCU進行了初始化、創建了內存管理相關的虛擬Domain、使能中斷、對SMP的預初始化、調用uart的驅動接口初始化postirq、嘗試啟動其余pcpu。最終start_xen()創建了特權域Domain0，并退化成為idle_vcpu。

軟中斷softirq執行路線

1.??硬/軟中斷觸發與執行

本質上，Xen的軟硬中斷觸發執行過程為：硬件中斷觸發軟件中斷TIMER_SOFTIRQ，TIMER_SOFTIRQ負責處理所有的軟定時器，軟定時器們有的負責觸發調度軟中斷、有的作為vcpu的虛擬定時器源。

a)??系統啟動時執行init_timer_interrupt();

b)??init_timer_interrupt()執行request_irq()，將硬件定時器處理函數指向timer_interrupt()。[26]

c)??timer_interrupt()函數會raise_softirq(TIMER_SOFTIRQ)，預計softirq將會在中斷返回處執行。

d)??do_softirq()[27]調用__do_softirq(0)執行所有在softirq_handlers中的軟中斷函數。

e)??核心函數指針數組softirq_handlers，記錄有軟中斷處理函數，其主要元素有TIMER_SOFTIRQ[28]

SCHEDULE_SOFTIRQ[29]

NEW_TLBFLUSH_CLOCK_PERIOD_SOFTIRQ

RCU_SOFTIRQ

TASKLET_SOFTIRQ

NR_COMMON_SOFTIRQS。

2.??軟中斷/定時器設置

a)??open_softirq()時會把處理函數設入softirq_handler函數指針數組。

b)??init_timer()會將軟定時器放入per-cpu變量timers，并設置軟定時器處理函數。

軟定時器機制struct timers和struct timer

1.??管理timer的timers

struct timers是per-cpu變量timers的數據結構，其中有struct timer，分為struct timer **heap，struct *list，struct timer *running，struct list_head inactive。

a)??structtimer **heap是一個timer堆，大概按照超時順序排列。如果發現所插入timer為堆內首個timer，則會軟件產生一個TIMER_SOFTIRQ，堆滿才用鏈表。

b)??structtimer list是一個timer鏈表，按照超時時間大小排列，在struct timer ** heap空間不夠時，才會用鏈表。發現所插入timer是鏈表第一個元素時會軟件產生TIMER_SOFTIRQ。

c)??structtimer running存放正在執行的timer，在timer的function被執行時會將其從timer堆或timer鏈表中移除，然后實際執行時被加入到running鏈表。

d)??structtimer inactive是timer被deactivate之后的存放之處。

2.??vcpu的timer

a)??periodic_timer

用于發生vcpu的虛擬定時器中斷。

b)??singleshot_timer

c)??poll_timer

3.??調度觸發的timer

per-cpu變量struct schedule_data中的s_timer軟定時器是調度的觸發定時器，當TIMER_SOFTIRQ觸發此軟定時器，軟定時器處理函數s_timer_fn()將會觸發SCHEDULE_SOFTIRQ軟中斷，發生調度。

4.??補充預算的timer-實時調度

structscheduler的sched_data元素指向實現調度器算法的私有數據結構，對于RT調度此數據為struct rt_private，rt_private中的repl_timer軟定時器是RT調度用于補充預算的定時器，每次補充預算完成后，會設置軟定時器的出發時間為下一個投入執行的vcpu的deadline。

5.??Domain的看門狗(默認每個域可有2個)

structdomain中的watchdog_timer[]軟定時器保存有Domain的看門狗定時器，若被觸發說明Domain沒有喂狗，可能出錯，會將Domain關閉。

6.??structvtimer的定時器

與Domain虛擬中斷相關的軟定時器，略。

總結

start_xen()啟動到當前位置并未完成，Xen調度相關初始化主線已經分析清楚。CPU硬件中斷[30]與處理函數綁定[31]，處理函數中會發起TIMER_SOFTIRQ軟中斷；系統軟中斷TIMER_SOFTIRQ綁定的處理函數[32]會執行所有當前pcpu掛載在timers中的軟定時器的處理函數；調度器的軟定時器處理函數是s_timer_fn()[33]，會觸發SCHEDULE_SOFTIRQ軟中斷；?SCHEDULE_SOFTIRQ軟中斷的處理函數為schedule()，是系統調度入口。[34]

一次調度的處理

Xen調度入口函數位于文件”./xen/common/schedule.c”中的static voidschedule(void)。調度的觸發方式會有多種，在Xen中確定已知的有定時觸發、中斷返回觸發、任務阻塞觸發[35]。所有觸發的調度最終都會傳導到schedule。

在schedule()

1.??switch( *tasklet_work )

tasklet_work[36]是當前pcputasklet work的狀態標志，可以為TASKLET_enqueued、TASKLET_scheduled以及TASKLET_enqueued|TASKLET_scheduled，如果僅有TASKLET_scheduled置位，表示不需要處理，否則調度器會執行idle_vcpu，idle_vcpu會執行do_tasklet()，并調整標志位。do_tasklet()會調用do_tasklet_work()，在do_tasklet_work()中，tasklet的func會被執行；只有在tasklet鏈表中不再有元素時，do_tasklet()會清除TASKLET_enqueued標志位。在TASKLET_enqueued標志位被清除時schedule()會清除TASKLET_scheduled。

2.??stop_timer(&sd->s_timer);

sd是當前pcpu的schedule_data，其中包含鎖、struct vcpu *curr[37]、void *sched_priv[38]、struct timer s_timer[39]、urgent的vcpu計數。各pcpu的struct timers數據[40]中有struct timer，分為struct timer **heap[41]，struct *list[42]，struct timer *running[43]，struct list_head inactive[44]，此處將struct timer->status設置為TIMER_STATUS_inactive，并加入timer所屬pcpu下struct timers數據的inactive鏈表。[45]

3.??next_slice= sched->do_schedule(sched, now, tasklet_work_scheduled);

調用當前pcpu的調度器計算下一個要投入運行的任務，其中next_slice包含3個元素：structvcpu *task[46]、s_time_t time[47]、bool_t migrated[48]；sched為調度器結構體，指向當前pcpu調度器指針；do_schedule()為調度器調度計算函數入口[49]；now=NOW()是CPU時間；tasklet_work_scheduled是tasklet需要調度投入執行的標志[50]。

4.??next =next_slice.task;

next是將會被投入運行的任務。

5.??sd->curr= next;

至此，schedule函數選好了投入運行的任務，記錄到sd的curr[51]。

6.??設置投運任務的運行時間

if (next_slice.time >= 0 ) set_timer(&sd->s_timer, now +next_slice.time);

next_slice.time只有在下一個任務使idle_vcpu的時候才會小于0；set_timer()將會給當前pcpu的調度定時器續時，時長決定于next_slice.time。

7.??省略

TRACE_3D()、TRACE_4D()會記錄調度的切換，不予分析；當計算完發現即將投入運行的任務還是之前的任務，則會直接投入運行。

8.??vcpu_runstate_change();

修改被調度出局任務的runstate，runstate記錄有vcpu在各狀態停留時間，根據被調度出局的原因：阻塞、離線、可執行[52]，是一個struct vcpu_runstate_info數據結構，包含int state[53]、uint64_t state_entry_time[54]、uint64_t time[4][55]。

9.??prev->last_run_time= now;

記錄被調度出局的vcpu的出局時間。

10.?vcpu_runstate_change(next,RUNSTATE_running, now);

記錄即將投運任務的runstate。

11.?next->is_running= 1;

標志著vcpu正在運行中。

12.?stop_timer(&prev->periodic_timer);

關閉調度出局的vcpu的periodic_timer，其處理函數為vcpu_periodic_timer_fn()[56]，periodic_timer的作用是向vcpu定時發出虛擬中斷信號[57]；此處將之關閉即不再發出此虛擬中斷。

13.?if (next_slice.migrated ) sched_move_irqs(next);

對于即將投入運行的vcpu，如果是從別的cpu遷移過來的，則需要調整他的IRQ到當前的cpu上[58]。

14.?vcpu_periodic_timer_work(next);

即將投入運行的vcpu的periodc_timer的啟動：首先檢測當前是否到vcpu的周期，決定是否發出virq；然后檢查并遷移periodic_timer到在當前pcpu名下[59]；最后設置vcpu下一個virq發生點。

15.?context_switch(prev,next);

進行了任務切換[60]。

描述Xen的調度單位vcpu

structvcpu?分析

vcpu是Xen的基本調度單位，其數據結構structvcpu復雜[61]，下面將分析其關鍵元素。

structrt_vcpu分析

struct rt_vcpu是RT調度專有數據結構，如下為全部元素：

Xen向GuestOS伸出了魔爪

之所以這么寫這個標題，是因為寫到這里，我發現，這一部分的解析才剛剛露出冰山一角，這一部分是指Xen作為Hypervisor對操作GuestOS的支撐部分，我在想是不是要在這個文檔里寫這個問題；因為這。。。不屬于調度了吧（還是屬于？）？這已經屬于GuestOS的調度基礎支撐了。

RT調度的do_schedule()

Xen的RT調度入口函數是位于文件”./xen/common/sched_rt.c”中的static struct task_slice?rt_schedule(conststruct scheduler *ops, s_time_t now,bool_t tasklet_work_scheduled)。主要處理：任務選擇，預算結算，返回所選擇的任務、將運行時間以及是否遷移自其他pcpu。本章將會分析rt_schedule()函數的實現。

1.??cpumask_clear_cpu(cpu,&prv->tickled);

從tickled中清楚當前pcpu位圖，tickled置位是因為執行了runq_tickle()，runq_tickle()有點發現優先級排序不對了，會整理，然后就會產生一次軟中斷調度[62]。

2.??burn_budget(ops,scurr, now);

將當前vcpu的預算結算掉(idle_vcpu除外)，對于RT調度，系統定義了私有的數據結構struct rt_vcpu[63]，其中的last_start元素[64]記錄上次投入運行的時間，可以計算出當前vcpu已經執行的時長[65]，在計算完后也要再次將last_start=now；cur_budget記錄vcpu運行時預算[66]，當cur_budget<=0，如果flags元素[67]中存在RTDS_exteratime標志[68]，則提升其優先級、補充其預算[69]，否則置位flags元素的RTDS_depleted標志[70]；

3.??tasklet_work_scheduled[71]被置位時：snext = rt_vcpu(idle_vcpu[cpu]);

有tasklet需要正式調度過去執行[72]，就不會發生runq_pick()[73]操作，即將要投入運行的任務將會是idle_vcpu，只需做一些記錄即可，作為空閑vcpu會不停地執行tasklet。

4.??snext=?runq_pick(ops, cpumask_of(cpu));

遍歷可執行vcpu鏈表，綜合vcpu所處Domain的有效pcpu位圖[74]、vcpu的硬親和pcpu位圖[75]和實際pcpu位圖[76]，得到下一個運行的vcpu[77]。需要注意的是這里的選擇vcpu并不考慮剩余預算的問題，如果沒有預算，系統將會失敗，也就是說，RunQ中vcpu必有預算。

5.??if (snext == NULL ) snext = rt_vcpu(idle_vcpu[cpu]);

如果沒有合適的vcpu被選到，則執行idle_vcpu。

6.??查看是否需要執行之前的vcpu

if(?!is_idle_vcpu(current)?&&??

vcpu_runnable(current)?&&

scurr->cur_budget > 0&&

(?is_idle_vcpu(snext->vcpu)?||compare_vcpu_priority(scurr, snext) > 0 )?)

snext = scurr

如果之前的vcpu，不是idle_vcpu、可執行[78]、預算存在并且新選的vcpu是idle_vcpu或比之前vcpu優先級低，則不會切換。

總結成人話就是：如果選完以后發現是空閑vcpu并且原先的vcpu不空閑，那么繼續執行之前的vcpu；如果選出的vcpu優先級不如之前的高，并且之前的vcpu還有預算，那么還是執行之前的vcpu。這是RT調度的重要原則之一。

7.??if (?snext != scurr?&&

!is_idle_vcpu(current)?&&

vcpu_runnable(current)?)

__set_bit(__RTDS_delayed_runq_add, &scurr->flags);

如果下一個要投入運行的vcpu不是當前vcpu，并且當前運行的vcpu也不是idle_vcpu，并且當前vcpu還是可執行；置位struct rt_vcpu->flags的__RTDS_delayed_runq_add[79]。

8.??snext->last_start= now;

更新下一個投入執行的vcpu的投入時間

9.??if (?snext->vcpu->processor != cpu?){

snext->vcpu->processor = cpu;

ret.migrated = 1;

}

檢查此vcpu是否遷移自非當前pcpu[80]，對于產生遷移的需要更新vcpu->processor；ret是是函數返回值task_slice數據結構，置位其migrated元素，提示遷移發生[81]。

10.?ret.time= snext->cur_budget;

cur_budget存有當前vcpu將會被投入運行的時長，放入在返回值struct task_slice中time元素[82]。

11.?ret.task= snext->vcpu;

將選定的vcpu設置到返回值中。

RT調度的預算補充

當vcpu的預算消耗完，需要補充預算的vcpu們會被放到ReplQ鏈表，由軟定時器repl_timer[83]觸發的處理函數repl_timer_handler()將會為之補充預算。下面將分析repl_timer_handler()功能。

1.??遍歷ReplQ鏈表，在遍歷過程中，會不斷給ReplQ中的vcpu元素補充預算、按周期延展deadline、將優先級置0，并加入到臨時鏈表等待進一步處理；預算補充完后，檢測如果vcpu還在RunQ/DeplQ，則會拔、插[84]回RunQ/DeplQ[85]。再次遍歷過程中，如果遇到deadline未到的vcpu應截止遍歷，僅處理已補充預算的vcpu。

2.??遍歷上一步補充過預算的vcpu，如果發現vcpu正在運行，但優先級并不比RunQ上的下一個vcpu高[86]，這是不合理的，觸發runq_tickle()[87]；如果vcpu不在執行，判斷其RTDS_depleted標志位(判斷完清除之)并確認其在RunQ/DeplQ，同樣觸發runq_tickle()。

RT調度的喚醒

vcpu任務的喚醒由rt_vcpu_wake()執行，對于以下vcpu狀態：

1.??vcpu正在指定的pcpu執行，更改per-cpu狀態vcpu_wake_running，喚醒結束。

2.??vcpu處于RunQ/DeplQ，更改per-cpu狀態vcpu_wake_onrunq，喚醒結束。

喚醒vcpu可直接執行完畢。

對于普通情況，檢測vcpu處于可執行狀態/不可執行狀態，相應的更改per-cpu狀態標志。如果vcpu的deadline已超時，更新其deadline、預算、last_start=now、優先級置0[88]；否則無需操作。如果vcpu RTDS_scheduled[89]置位，則置位RTDS_delayed_runq_add，以便于在此vcpu經過rt_context_saved()時會將之加入RunQ/DeplQ；如果之前判斷deadline超時，則此處需要將其在ReplQ上插拔一次，以防止其在ReplQ鏈表不存在或順序問題，完成后喚醒即結束。對于vcpu RTDS_scheduled未置位，即vcpu未在pcpu上執行，則需要將其插入ReplQ、RunQ/DeplQ、然后用runq_tickle()檢查一下是否該觸發軟中斷[90]，喚醒結束。

RT調度的優先級

RT調度的優先級首先由struct rt_vcpu->priority_level決定，priority_level越小的vcpu優先級越高；在同優先級的情況下，會比較structrt_vcpu->cur_deadline，deadline越近的vcpu優先級越高。具體可查看函數compare_vcpu_priority()。

RT調度的數據結構

RT調度有3個鏈表[91]，由所有的pcpu[92]共享一個是有序[93]的RunQ鏈表，鏈接有預算且可執行的vcpu；一個是無序DeplQ鏈表，鏈接沒有預算等待補充預算之后就能跑的vcpu；最后是一個有序[94]的ReplQ鏈表，鏈接等待補充預算的vcpu。

RunQ和DeplQ是互斥的兩個鏈表，即一個vcpu不能同時在RunQ和DeplQ上；但一個vcpu應該同時在RunQ和ReplQ上，或同時在DeplQ和ReplQ上。

ReplQ只能在vcpu喚醒、初創的時候，插入RunQ/DeplQ(或is_running態)才會被插入ReplQ；當vcpu不再被調度時，需要離開ReplQ(也會離開RunQ/DeplQ)。

如果vcpu是由于進入睡眠[95]、被銷毀[96]、遷移離開調度[97]，則離開3大鏈表。

RT調度的deadline

RT調度的deadline位于rt_vcpu->cur_deadline，唯一可以補充cur_deadline的位置是rt_update_deadline()，而在普通運行階段[98]，唯有軟定時器repl_tmer的處理函數repl_timer_handler()會調用rt_update_deadline()為vcpu更新deadline，軟定時器repl_timer的觸發時間總是按照RunQ即將投入運行的任務的cur_deadline設定。

進一步

經過上述分析可以全面的了解Xen調度的前因后果，RT調度的實現考量，之后還需要進一步分析以及目前Xen的調度在ARM平臺存在的一些問題如下。

1.??總結分析可能觸發調度的點。

2.??Xen對vcpu的切換過程，如寄存器保存、新寄存器值設入。

3.??Xen在已啟動的pcpu中如何啟動其他pcpu。

在vcpu_initialise()時，會有

???vcpu->arch.saved_context.sp = (register_t)v->arch.cpu_info;

???vcpu->arch.saved_context.pc = (register_t)continue_new_vcpu;

????是如何工作的。

4.??目前的RT調度，各CPU均采用同一任務鏈表，調度需要獲取鎖，是存在存在競爭、浪費的。

5.??Xen跨CPU調度僅根據一些固定設置，不是阻尼的方式防止，這很明顯會引起不必要的cachemiss降低效率。

6.??Xen不能感知GuestOS的空閑、于是當vcpu執行idle線程時，Xen也不會有動作，是否可以修改GuestOS的idle線程。

7.??Xen對大小核并未考慮。

?

[1]?Xen應該是繼承自Linux的各pcpu變量定義：DECLARE_PER_CPU(unsignedint, cpu_id)是獲得已被定義的per-cpu變量。一次引用聲明，各pcpu分別有了cpuid變量，當代碼所處pcpu執行this_cpu(cpuid)，即可獲得此pcpu的cpuid

[2]?具體代碼為this_cpu(cpuid)=0，第一個percpu變量的使用實例。

[3]?idle_vcpu是一個全局數組，每一個物理pcpu都會有一個idle_vcpu，當這個物理pcpu沒有任務時，就會把它取出來執行。

[4]?current是一個宏變量，通過this_vcpu(curr_vcpu)獲得，即為本物理pcpu中執行的vcpu。

[5]?Xen想要將所有的執行進程都作為vcpu來表述，可以理解為vcpu即為Xen的進程，vcpu是Xen微內核的關鍵概念，后續還會提到并解釋。

[6]?idle_vcpu是Xen中空閑進程的。

[7]?想象沒有CPU對虛擬化的硬支持，Xen如何實現對GuestOS的管控：對于GuestOS下發的每一條計算機指令，Xen都需要將這條指令檢查過之后再投入計算機執行，如同Java的虛擬機(效率更低)，效率就像是笑話(CPU50%以上的時間在檢查指令)。但如果不這樣做，一旦被GuestOS獲得CPU的使用權，GuestOS將會獲得完整的硬件使用權，如果GuestOS將硬件調度定時器的處理函數指向自己的調度函數，Xen就會像BootLoader一樣被扔到一邊，之后的GuestOS也都成為廢紙，所謂域間隔離也都只能是空談。

[8]?CP15 CR12下HVBAR是Hypervisor的Vector Base Address Register存儲異常向量地址；注意aarch64，與aarch32一些特權寄存器使用方式有變化。

[9]?early_fdt_map()調用的create_mappings()函數透露出Xen對內存管理的信息，但由于本文檔重點分析Xen的調度機制，在此不予詳述。

[10]?Xen的狀態可能為：SYS_STATE_early_boot、SYS_STATE_boot、SYS_STATE_smp_boot、SYS_STATE_active、SYS_STATE_suspend、SYS_STATE_resume等

[11]?其他還有IRQ_TYPE_NONE(默認的普通IRQ_TYPE)、IRQ_TYPE_EDGE_RISING(上升沿觸發的中斷)、IRQ_TYPE_EDGE_FALLING(下降沿觸發的中斷)、IRQ_TYPE_EDGE_BOTH(上升、下降沿均會觸發的中斷)，其他還有IRQ_TYPE_LEVEL_HIGH、IRQ_TYPE_LEVEL_LOW、IRQ_TYPE_LEVEL_MASK、IRQ_TYPE_SENSE_MASK等類型或組合類型的中斷。

[12]?此處Xen需要的初始化的接口少的可憐，init()估計是留給廠商將硬件啟動，init_time()獲得硬件提供的一個定時器來作為系統的時鐘滴答(內核基于此感知時間，如觸發調度，超時操作)；specific_mapping()讓廠商把外設的內存地址送到struct domain，后期啟動Dom0時，Dom0能看到外設。另外Xen還需要廠商提供的reset()、poweroff()，估計是重啟、關機操作。另外還可以有給出一個禁止pass-through的設備表告訴Xen。quirks()函數未知。arm32還會有smp_init()、cpu_up()函數。

[13]?對于啟動了ACPI的設備，ACPI會接管初始化操作

[14]?這可能是Xen作為一個域的編號7FF2U，Dom0由此編號訪問Hypervisor(如xl對Xen的操作？)。

[15]?啟動時間的記錄在boot_count，從P15 CR14讀出。

[16]?GIC是中斷控制器，對于無ACPI平臺，系統直接讀DTB完成初始化，對于有ACPI節點，由ACPI提供的接口完成。

[17]?Xen中tasklet.c源碼中顯示是由1992年Linus Torvalds的代碼基礎上修改而來，總體機制變化不大。

[18]?Notifiter是內核的常用通信機制，主體為一個按優先級排列的鏈表，被插入當前pcpu下。

[19]?scheduled_on>=0表示此tasklet應該放在某pcpu上執行，而scheduled_on的值即為pcpu的id，因此應被放到對應pcpu的softirq_tasklet_list或tasklet_list，如果為-1則不會特別處理。

[20]?is_softirq將會只能在軟中斷處理。

[21]?加入softirq_tasklet_list的同時，指定pcpu的softirq_tasklet_list無內容，則為此CPU軟產生一個TASKLET_SOFTIRQ軟中斷。

[22]?加入tasklet_list時若指定pcpu的tasklet_list無內容則為此CPU軟產生一個SCHEDULE_SOFTIRQ。

[23]?在REF _Ref517287190 \h??\* MERGEFORMAT?一次調度的處理?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003200380037003100390030000000，?REF_Ref517287151 \h??\* MERGEFORMAT?next_slice = sched->do_schedule(sched, now,tasklet_work_scheduled); 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003200380037003100350031000000會用到此變量。

[24]?timer_irq數組有四個成員TIMER_PHYS_SECURE_PPI、TIMER_PHYS_NONSECURE_PPI、TIMER_VIRT_PPI、TIMER_HYP_PPI，詳見章節REF _Ref517685421 \h??\* MERGEFORMAT?軟中斷softirq執行路線?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003600380035003400320031000000。

[25]?TIMER_SOFTIRQ的處理函數)是所有軟中斷啟動之源

[26]?timer_irq數組記錄有定時器中斷資源，將與處理函數timer_interrupt()連接；timer_irq數組有四個成員及其處理函數：TIMER_PHYS_SECURE_PPI(可能是TZ相關)、TIMER_PHYS_NONSECURE_PPI <->timer_interrupt、???TIMER_VIRT_PPI <->timer_interrupt、TIMER_HYP_PPI<->timer_interrupt。

[27]?分析猜測do_softirq()

[28]?由硬件中斷觸發

[29]?由軟定時器觸發，軟定時器由TIMER_SOFTIRQ觸發；這就是調度的軟中斷。

[30]?詳情見章節REF _Ref517291038 \h??\* MERGEFORMAT?在start_xen()?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F00520065006600350031003700320039003100300033003800000012.init_IRQ()、14.preinit_xen_time()、15.init_xen_time()。

[31]?詳情見章節REF _Ref517291038 \h??\* MERGEFORMAT?在start_xen()?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F00520065006600350031003700320039003100300033003800000019. init_timer_interrupt()。

[32]?詳情見章節REF _Ref517291038 \h??\* MERGEFORMAT?在start_xen()?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F00520065006600350031003700320039003100300033003800000020.timer_init()。

[33]?詳情見章節REF _Ref517291038 \h??\* MERGEFORMAT?在start_xen()?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F00520065006600350031003700320039003100300033003800000021.init_idle_domain()。

[34]?根據Linux內核，軟中斷的處理會在中斷退出時發生，可能寫在匯編代碼中，內核代碼中找到的對do_softirq函數的調用，并不能確認有效。

[35]分析能觸發調度的時機是非常重要的，但由于能力所限，短時間內不能枚舉，此處僅列舉分析過程中確定可以觸發調度的時機。

[36]?tasklet_work=&this_cpu(tasklet_work_to_do)是當前pcpu變量，由DECLARE_PER_CPU定義。

[37]?當前正在運行的任務vcpu數據結構指針。

[38]?這是調度器的私有數據結構入口。

[39]?調度定時器，軟中斷將會處理其內function函數。

[40]?struct timers也是per-cpu變量，依舊是繼承自Linux的各pcpu變量定義，struct timers并未被DECLARE_PER_CPU引用聲明，由宏DEFINE_PER_CPU定義，DEFINE_PER_CPU是對per-cpu變量的真實定義，而DECLARE_PER_CPU是對per-cpu變量的引用聲明。&this_cpu(a)訪問本pcpu的per-cpu變量&per_cpu(a,cpu0)訪問cpu0核的per-cpu變量。

[41]根據add_to_heap()和remove_from_heap()的分析，struct timer **heap是一個timer堆，大概按照超時順序排列。如果發現所插入timer為堆內首個timer，則會軟件產生一個TIMER_SOFTIRQ，堆滿才用鏈表。

[42]?struct timers中的struct timer list是一個timer鏈表，按照超時時間大小排列，在struct timer ** heap空間不夠時，才會用鏈表。發現所插入timer是鏈表第一個元素時會軟件產生TIMER_SOFTIRQ。

[43]?struct timers中的struct timer running在timer的function被執行時(見20.中timer_softirq_action())，會從timer堆或timer鏈表中移除，然后實際執行時(execute_timer())被加入到running鏈表。

[44]?struct timers中的struct timer inactive是timer被deactivate之后的存放之處。

[45]?timers和timer有著完整的機制描述，可在章節?REF _Ref517280274 \h? \* MERGEFORMAT?軟定時器機制struct timers和struct timer?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003200380030003200370034000000查看。

[46]?vcpu是Xen調度的基本單位。

[47]?指示當前task_slice將會運行多久，主要來自調度器自定數據結構中xx_vcpu->cur_budget。

[48]?指示這個任務是否是從其他pcpu遷移到這里的。

[49]?下文分析了?REF _Ref517285580 \h? \* MERGEFORMAT?RT調度的do_schedule()?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003200380035003500380030000000的實現。

[50]?tasklet_work_scheduled的設置在本章?REF_Ref517287690 \r \h??\* MERGEFORMAT?1 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003200380037003600390030000000.處完成在RT調度中，tasklet_work_scheduled置位會使調度器在選擇任務使選中idle_vcpu，idle_vcpu內有tasklet處理函數入口do_tasklet()。

[51]?sd變量描述同本章?REF _Ref517288519 \r \h? \* MERGEFORMAT?2 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003200380038003500310039000000

[52]?可執行狀態RUNSTATErunnable遇到tasklet占用、高優先級的vcpu等是會被調度出去的。

[53]?state元素記錄vcpu當前所處狀態：RUNSTATE_running、RUNSTATE_runnable、RUNSTATE_blocked、RUNSTATE_offline，詳情可見章節?REF _Ref517290931 \h? \* MERGEFORMAT?描述Xen的調度單位vcpu?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003200390030003900330031000000。

[54]?vcpu進入當前狀態的時間。

[55]?state元素的4個狀態，分別對應數組中的四個元素，記錄有當前vcpu在四個狀態的累計時間。

[56]?init_timer(&v->periodic_timer,vcpu_periodic_timer_fn, v, v->processor);詳見章節REF _Ref517280274 \h??\* MERGEFORMAT?軟定時器機制structtimers和struct timer?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003200380030003200370034000000。

[57]?通過evtchn_port_set_pending()向vcpu發送了一個中斷信號，章節’?REF _Ref517344185 \h? \* MERGEFORMAT?Xen向GuestOS伸出了魔爪?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003300340034003100380035000000可能有。

[58]?這又是一個大活兒啊，另外還涉及到Xen對中斷機制的操作，同樣去章節’?REF _Ref517344185 \h? \* MERGEFORMAT?Xen向GuestOS伸出了魔爪?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003300340034003100380035000000可能有。

[59]?migrate_timer()完成，詳見章節?REF_Ref517280274 \h??\* MERGEFORMAT?軟定時器機制structtimers和struct timer?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003200380030003200370034000000(不一定有)。

[60]?context_switch()需要做很多很多事，不過功能卻只有一個，任務切換，于是先不分析細節。

[61]?還好我已經搞明白了不少。

[62]?查找到3處使用runq_tickle()的位置，分別是vcpu剛醒、上下文切換時剛保存完當前vcpu現場，調度完

[63]?詳見章節REF _Ref517353329 \h??\* MERGEFORMAT?RT調度的私有數據結構?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003300350033003300320039000000。

[64]?下文中REF _Ref517362375 \h??\* MERGEFORMAT?snext->last_start = now; 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003300360032003300370035000000在下一個vcpu投入運行前更新了此元素。

[65]?在注釋中看到，這個時長計算在嵌入式虛擬化中似乎會出現負數的錯誤，并未弄清如何產生。

[66]?在此處RT調度的預算只可能被減少，另外有一個timer會調用repl_timer_handler()來為失去預算的vcpu補充預算。詳見章節REF _Ref517354017 \h??\* MERGEFORMAT?RT調度的預算補充?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003300350034003000310037000000。

[67]?flags同樣是struct rt_vcpu的元素，定義有詳盡的標志位，詳見章節REF _Ref517353329 \h??\* MERGEFORMAT?RT調度的私有數據結構?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003300350033003300320039000000。

[68]?根據注釋，RTDS_extratime標志是想讓進程有多x輪的預算，以至于在沒有優先級比他高的vcpu，他就可以一直跑？因為默認sched_init_vcpu()創建vcpu時都會alloc_vdata()，alloc_vdata()是scheduler的接口，在RT的實現都給加了此標志。只有在hypercall的do_domctl() XEN_DOMCTL_SCHEDOP_putvcpuinfo操作是沒有XEN_DOMCTL_SCHEDRT_extra標志時，才會被清楚此標志位。

[69]?我很懷疑這種操作的合理性，

[70]?表示vcpu預算耗盡，在之后的處理中將會被加入到預算耗盡的vcpu鏈表，等待補充預算。

[71]?tasklet需要處理標志，詳見REF _Ref517358187 \h??\* MERGEFORMAT?在schedule()?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003300350038003100380037000000的?REF_Ref517287690 \h??\* MERGEFORMAT?switch ( *tasklet_work ) 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003200380037003600390030000000。

[72]?此種情況發生在tasklet_list的任務在tasklet觸發后，發現需要此pcpu執行，即當前pcpu的tasklet_work_to_do被置位了，于是在調度時遇到，則需要執行。詳見章節REF _Ref517291038 \h??\* MERGEFORMAT?在start_xen()?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003200390031003000330038000000的?REF_Ref517357878 \h??\* MERGEFORMAT?tasklet_subsys_init(); 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003300350037003800370038000000

[73]?算法選擇可投入執行的vcpu

[74]?vcpu所在struct domain中有struct cpupool，cpupool內cpu_valid用位圖表示可用pcpu們。

[75]?vcpu中有cpu_hard_affinity位圖，表示vcpu僅可在哪幾個pcpu上執行。

[76]?smp_processor_id()可獲得。

[77]?找到的第一個vcpu即為投入運行的vcpu，于是此鏈表順序很重要，包含調度原則。

[78]?沒有暫停標志和暫停計數，并且其所在域也沒有

[79]?在rt_context_saved()這個vcpu會被加入到RunQ，rt_context_saved()是在啟動投運vcpu前執行的context_saved()里調用。

[80]?跨pcpu的任務遷移必然會引起大量cache miss，降低效率，因此原則上跨pcpu的調度應該有一定阻尼，很明顯Xen的RT沒有做。

[81]章節?REF_Ref517358187 \h??\* MERGEFORMAT?在schedule()?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003300350038003100380037000000中?REF_Ref517287151 \h??\* MERGEFORMAT?next_slice = sched->do_schedule(sched, now,tasklet_work_scheduled); 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003200380037003100350031000000也有介紹，?REF_Ref517362153 \h??\* MERGEFORMAT?if ( next_slice.migrated ) sched_move_irqs(next); 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003300360032003100350033000000同樣根據此處判斷結果。

[82]?章節REF _Ref517358187 \h??\* MERGEFORMAT?在schedule()?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003300350038003100380037000000中?REF_Ref517363192 \h??\* MERGEFORMAT?設置投運任務的運行時間?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003300360033003100390032000000時使用此元素。

[83]?詳見章節REF _Ref517280274 \h??\* MERGEFORMAT?軟定時器機制structtimers和struct timer?08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500310037003200380030003200370034000000。

[84]?先從RunQ/DeplQ鏈表取出，再插入，可以重新決定vcpu進RunQ/DeplQ，如果進入RunQ還可以重新排列其位置。

[85]?此處預算剛補充完畢，應該會插回RunQ。

[86]?因為Xen的RT調度所有pcpu共用待RunQ鏈表，經過重新充能先后時可能出現低優先級被先執行的情況的。

[87]?runq_tickle()會檢查指定scheduler的新加vcpu是否有機會調度，如果有，則觸發調度軟中斷。

[88]?rt_update_deadline()操作。

[89]?標志vcpu在pcpu上執行。

[90]?如果被喚醒vcpu優先級高的話。

[91]?每個RT調度的scheduler實體有3個鏈表，多個scheduler(RT/Credit)共存是可能的。

[92]?源文件中存在注釋表述的是CPU pool，用pcpu是為了不用解釋CPU pool。

[93]?排列順序是優先級高在前，同優先級的deadline緊急的靠前。

[94]?排列順序同樣是優先級高在前，同優先級的deadline緊急的靠前與RunQ用同樣的插入函數和優先級比較方式。

[95]?rt_vcpu_sleep()是調度器接口sleep的RT實現

[96]?rt_vcpu_remove()是調度器接口remove_vcpu的RT實現，在銷毀vcpu(sched_destroy_vcpu())、遷移domain(sched_move_domain())被使用。

[97]?rt_context_saved()是調度器context_saved的RT實現，

[98]?vcpu初始化、vcpu喚醒也會執行rt_update_deadline()操作。

?