一种基于硬件的虚拟化设计简化多核处理器的方案

图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 系统稳定性

一个应用有时可能会尝试使用某个并不具备访问权的资源。程序中的错误可能造成这种情况的出现，此时只有部分刷新的应用在使用中，或者当代码或数据内存出现被覆盖情况时。必须防止一个应用干扰到其它应用，即：写入到其它应用的内存空间；或对性能产生负面影响，例如，获取对某个共享资源的控制。在基于软件的资源共享实现中，一个损坏的应用可能忽视自己的带宽配额，而去独占一个共享资源。同样，如果掌控虚拟化的处理器损坏，则队列机制就会失效，使整个系统宕机。