一種基于硬件的虛擬化設(shè)計(jì)簡化多核處理器的方案

圖3.（a）隨著處理器數(shù)量的增長，資源共享的復(fù)雜性與開銷也在增加

（b）除卸載了隊(duì)列與流量管理工作以外，資源共享變得對應(yīng)用透明

2.1 虛擬化增加了開銷和復(fù)雜性，限制了多核SoC的使用

不過，隊(duì)列和流量管理是一個(gè)相當(dāng)確定性的過程，可以采用硬件實(shí)現(xiàn)。開發(fā)人員為某個(gè)應(yīng)用配置一次隊(duì)列，然后硬件機(jī)制就可以完整地卸下隊(duì)列管理負(fù)載，因此將相當(dāng)多的計(jì)算周期還給了應(yīng)用處理器。動(dòng)態(tài)改變分配的能力使得可以在運(yùn)行時(shí)修改配置，以適應(yīng)不斷變化的工作負(fù)載。

在一個(gè)采用基于硬件的隊(duì)列與同步機(jī)制的架構(gòu)中，每個(gè)處理器都獨(dú)立于其它處理器而運(yùn)行（圖3b）。通過資源的虛擬化，共享就對應(yīng)用透明了。機(jī)制會分配每個(gè)處理器和每個(gè)任務(wù)的資源帶寬，而每個(gè)處理器和任務(wù)運(yùn)行時(shí)則像是資源唯一控制方。盡管不同應(yīng)用實(shí)現(xiàn)隊(duì)列和流量管理的粒度并不相同，但基于硬件的資源虛擬化與共享能顯著提高系統(tǒng)的效率。

2.2 基于硬件的虛擬化層去除或加快了軟件虛擬化層

虛擬化的卸載顯著增加了處理器的效率。在某些情況下，基于硬件的虛擬化完全不需要基于軟件的虛擬化，除了在初始配置期間。還有一些情況下，基于硬件的隊(duì)列與流量管理大大加快了數(shù)據(jù)路徑中虛擬化軟件的速度。

2.3 基于硬件的虛擬化層還降低了設(shè)計(jì)的復(fù)雜性，加快了開發(fā)進(jìn)度

因?yàn)樗恍枰_發(fā)人員圍繞虛擬化層作實(shí)現(xiàn)和設(shè)計(jì)。這種方案簡化了設(shè)計(jì)，加快了上市時(shí)間。

2.4 基于硬件的虛擬化層還提高了確定性

由于沒有了虛擬化開銷，就減少了系統(tǒng)中斷的重要來源。于是降低了處理延時(shí)，增加了系統(tǒng)的響應(yīng)能力。

這種方案的另一個(gè)好處是簡化了調(diào)試工作。由于虛擬化和資源共享都是硬件功能，虛擬化層本身就不是開發(fā)過程的一部分。但如調(diào)試有要求，開發(fā)人員仍然擁有對隊(duì)列的完全訪問和控制能力?；谟布奶摂M化層還增加了可靠性，因?yàn)橛布?shí)現(xiàn)的隊(duì)列和流量管理不易受很多在軟件實(shí)現(xiàn)中容易出現(xiàn)的問題的影響。例如，如果基于軟件的代碼處理虛擬化有所折衷，則整個(gè)系統(tǒng)就很脆弱。采用基于硬件的實(shí)現(xiàn)時(shí)，就不存在有受損危險(xiǎn)的中心化控制例程。

3 處理器卸載

所支持的隊(duì)列卸載水平與實(shí)現(xiàn)有關(guān)。例如，有些SoC可能提供鎖定機(jī)制，但并不管理隊(duì)列的全部狀態(tài)。理想情況下，開發(fā)人員想要一個(gè)支持不同配置的靈活系統(tǒng)，能直接與軟件整合，并盡可能減少為適應(yīng)SoC而做的軟件修改。一個(gè)虛擬化機(jī)制可能很有效；但是，如果要與傳統(tǒng)編程模型有大的變化，則移植應(yīng)用代碼會增加系統(tǒng)成本，延遲上市時(shí)間。

實(shí)現(xiàn)隊(duì)列的方式也會影響到系統(tǒng)的性能。例如，隊(duì)列的位置影響著哪些處理器可以訪問這些隊(duì)列。有些隊(duì)列必須以內(nèi)存類型存在，在整個(gè)芯片上分布，或者被捆綁到某個(gè)資源上。動(dòng)態(tài)分配的隊(duì)列使開發(fā)人員擁有某種靈活性，能恰當(dāng)?shù)貙㈥?duì)列劃分給應(yīng)用和資源。對于采用多只多核SoC的系統(tǒng)，如擁有通過一個(gè)系統(tǒng)總線（如PCIe）管理隊(duì)列的能力，則資源的共享不僅能在同一SoC的不同核心之間，而且能在不同SoC之間。例如，一個(gè)處理簇可以共享單個(gè)轉(zhuǎn)發(fā)數(shù)據(jù)庫。另外，一個(gè)多SoC系統(tǒng)可能擁有一個(gè)單一的深層數(shù)據(jù)包檢查引擎，而運(yùn)行在不同SoC上的應(yīng)用必須訪問該引擎。這種多芯片的資源共享能夠?qū)崿F(xiàn)更進(jìn)一步的系統(tǒng)資源虛擬化。

多芯片架構(gòu)中最大的設(shè)計(jì)挑戰(zhàn)之一是用某種方式的分區(qū)工作，以將資源需求平均地分配給所有處理器。在基于軟件的虛擬化中，這個(gè)過程可能非常耗時(shí)，為設(shè)計(jì)人員增加了負(fù)擔(dān)，包括高效管理空閑內(nèi)存池的挑戰(zhàn)。另外，軟件的任何修改都可能為資源需求帶來變化，這就需要開發(fā)人員重新劃分系統(tǒng)分區(qū)。非對稱和對稱多處理器架構(gòu)都有很多這類問題。

采用基于硬件的虛擬化時(shí)，大多數(shù)分區(qū)管理任務(wù)放在硬件上，而操作系統(tǒng)則處理少量剩余任務(wù)。由于采用這種抽象分區(qū)，開發(fā)人員于做系統(tǒng)修改時(shí)，無需對系統(tǒng)做手工的重新分區(qū)。這種方案亦卸載了應(yīng)用與操作系統(tǒng)的一些任務(wù)，如管理空閑的內(nèi)存池。

4 帶寬保證

對一個(gè)資源的控制亦擴(kuò)展了一只處理器可以接受的最大分配限度，解決了接收端的處理瓶頸問題。例如，對于很多通信、音視頻、數(shù)據(jù)采集以及測試與測量應(yīng)用，接收處理器都有預(yù)期或可以處理的最大傳輸數(shù)據(jù)速率。在這些情況下，即使外設(shè)擁有更多的能力（因?yàn)槠渌幚砥鳟?dāng)前未使用它們的分配額），應(yīng)用也不希望隊(duì)列以更快的速率刷新，因?yàn)檫@種刷新可能超出接收處理器的能力，造成數(shù)據(jù)損失。

很多開發(fā)人員在設(shè)計(jì)時(shí)會采用最差情況方法；他們要確認(rèn)有足夠的容量支持最差情況的負(fù)載。但是，在典型工作條件下，這種方法無法用到全部的資源容量。例如，一個(gè)典型的輪轉(zhuǎn)仲裁算法僅支持最低的配額。如果系統(tǒng)對某個(gè)資源有多達(dá)10個(gè)請求方，則每個(gè)請求方總是可以期望擁有至少10%的帶寬。然而，如果僅有一個(gè)請求方活動(dòng)，則該請求方可以獲得100%的帶寬。

虛擬與透明的資源分配方法意味著一個(gè)應(yīng)用并不知道自己可能獲得多少帶寬。對于接收端存在瓶頸的應(yīng)用，為某個(gè)資源設(shè)定最大配額的能力對系統(tǒng)的穩(wěn)定非常重要。這個(gè)最大值使開發(fā)人員能夠控制每個(gè)應(yīng)用的資源帶寬（無論采用了何種分配算法），以防止淹沒接收端的處理器，并且防止了數(shù)據(jù)損失。開發(fā)人員還擁有用標(biāo)準(zhǔn)機(jī)制去管理擁塞的選擇，如IEEE 802.1Qav或802.1Qau。

5 系統(tǒng)穩(wěn)定性

一個(gè)應(yīng)用有時(shí)可能會嘗試使用某個(gè)并不具備訪問權(quán)的資源。程序中的錯(cuò)誤可能造成這種情況的出現(xiàn)，此時(shí)只有部分刷新的應(yīng)用在使用中，或者當(dāng)代碼或數(shù)據(jù)內(nèi)存出現(xiàn)被覆蓋情況時(shí)。必須防止一個(gè)應(yīng)用干擾到其它應(yīng)用，即：寫入到其它應(yīng)用的內(nèi)存空間；或?qū)π阅墚a(chǎn)生負(fù)面影響，例如，獲取對某個(gè)共享資源的控制。在基于軟件的資源共享實(shí)現(xiàn)中，一個(gè)損壞的應(yīng)用可能忽視自己的帶寬配額，而去獨(dú)占一個(gè)共享資源。同樣，如果掌控虛擬化的處理器損壞，則隊(duì)列機(jī)制就會失效，使整個(gè)系統(tǒng)宕機(jī)。