一種基于硬件的虛擬化設計簡化多核處理器的方案

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

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

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

不過，隊列和流量管理是一個相當確定性的過程，可以采用硬件實現。開發人員為某個應用配置一次隊列，然后硬件機制就可以完整地卸下隊列管理負載，因此將相當多的計算周期還給了應用處理器。動態改變分配的能力使得可以在運行時修改配置，以適應不斷變化的工作負載。

在一個采用基于硬件的隊列與同步機制的架構中，每個處理器都獨立于其它處理器而運行（圖3b）。通過資源的虛擬化，共享就對應用透明了。機制會分配每個處理器和每個任務的資源帶寬，而每個處理器和任務運行時則像是資源唯一控制方。盡管不同應用實現隊列和流量管理的粒度并不相同，但基于硬件的資源虛擬化與共享能顯著提高系統的效率。

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

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

2.3 基于硬件的虛擬化層還降低了設計的復雜性，加快了開發進度

因為它不需要開發人員圍繞虛擬化層作實現和設計。這種方案簡化了設計，加快了上市時間。

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

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

這種方案的另一個好處是簡化了調試工作。由于虛擬化和資源共享都是硬件功能，虛擬化層本身就不是開發過程的一部分。但如調試有要求，開發人員仍然擁有對隊列的完全訪問和控制能力。基于硬件的虛擬化層還增加了可靠性，因為硬件實現的隊列和流量管理不易受很多在軟件實現中容易出現的問題的影響。例如，如果基于軟件的代碼處理虛擬化有所折衷，則整個系統就很脆弱。采用基于硬件的實現時，就不存在有受損危險的中心化控制例程。

3 處理器卸載

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

實現隊列的方式也會影響到系統的性能。例如，隊列的位置影響著哪些處理器可以訪問這些隊列。有些隊列必須以內存類型存在，在整個芯片上分布，或者被捆綁到某個資源上。動態分配的隊列使開發人員擁有某種靈活性，能恰當地將隊列劃分給應用和資源。對于采用多只多核SoC的系統，如擁有通過一個系統總線（如PCIe）管理隊列的能力，則資源的共享不僅能在同一SoC的不同核心之間，而且能在不同SoC之間。例如，一個處理簇可以共享單個轉發數據庫。另外，一個多SoC系統可能擁有一個單一的深層數據包檢查引擎，而運行在不同SoC上的應用必須訪問該引擎。這種多芯片的資源共享能夠實現更進一步的系統資源虛擬化。

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

采用基于硬件的虛擬化時，大多數分區管理任務放在硬件上，而操作系統則處理少量剩余任務。由于采用這種抽象分區，開發人員于做系統修改時，無需對系統做手工的重新分區。這種方案亦卸載了應用與操作系統的一些任務，如管理空閑的內存池。

4 帶寬保證

對一個資源的控制亦擴展了一只處理器可以接受的最大分配限度，解決了接收端的處理瓶頸問題。例如，對于很多通信、音視頻、數據采集以及測試與測量應用，接收處理器都有預期或可以處理的最大傳輸數據速率。在這些情況下，即使外設擁有更多的能力（因為其它處理器當前未使用它們的分配額），應用也不希望隊列以更快的速率刷新，因為這種刷新可能超出接收處理器的能力，造成數據損失。

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

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

5 系統穩定性

一個應用有時可能會嘗試使用某個并不具備訪問權的資源。程序中的錯誤可能造成這種情況的出現，此時只有部分刷新的應用在使用中，或者當代碼或數據內存出現被覆蓋情況時。必須防止一個應用干擾到其它應用，即：寫入到其它應用的內存空間；或對性能產生負面影響，例如，獲取對某個共享資源的控制。在基于軟件的資源共享實現中，一個損壞的應用可能忽視自己的帶寬配額，而去獨占一個共享資源。同樣，如果掌控虛擬化的處理器損壞，則隊列機制就會失效，使整個系統宕機。