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

引言

今天的SoC（系统单芯片）处理器都集成了一系列的核心、加速器和其它处理单元。这些异质的多核架构提供了更多的计算能力，但其复杂性也为各种应用中嵌入系统的开发人员带来了新的挑战，这些应用包括控制层处理器、视频服务器、无线基站，以及宽带网关等。如果是分立的核心，每个核心都能完全地访问和控制自己的资源。这种可预测的访问能够做直接的管理，而有实时约束的应用也具备了确定的性能。然而，在一个多核架构中，各个核心共享资源，潜在的竞争使很多设计因素复杂化，例如处理延时以及可靠地中断处理。

为了提供与单核器件相当的确定性能，多核架构开始采用已经过网络通信验证的资源共享与管理技术。这些架构使用已有的队列与流量管理技术，在多个核心之间有效地分配资源、使吞吐量最大化、尽可能减小响应延时，并且避免了不必要的拥挤。

1 资源虚拟化

从架构的角度看，SoC是多核心的复杂系统，它通过一个高速结构，将各种控制与资源连接起来（图1）。在很多方式上，一片SoC内部的无数交互操作都很像一个有很多资源（或核心）的通信网络，这些资源与相同目的地做交互操作，包括内存、外设与总线。显然，设计人员用于提高网络效率的带宽管理技术（如虚拟化）也能用于管理多处理器核心以及共享外设之间的流量。

图1.下一代SOC是多核心访问相同的共同资源的复杂系统

片上资源的虚拟化使各个核心能够共享访问权；这种共享的访问权对应用是透明的。每个应用都可以把一个资源看作像自己独有一样，而一个虚拟化管理器用于汇总共享的所有权（由所分配的带宽量所测定）。对资源的虚拟访问和共享访问都需要一个队列管理器和一个流量管理器。各应用使用一个或多个队列，缓存对某个资源的访问。虚拟化为队列增加事件或事务，当资源可用时将它们从队列中拉出。队列包含了一个指向缓冲区中数据的缓存描述符（buffer descriptor），并且实现队列可以有多种方式，具体取决于应用的需求。一只SoC所支持的队列数是不定的，从数百个到数万个，可满足各种应用的需求。

队列管理器可刷新队列的状态，即：队列大小、头指针、尾指针，以及起始地址，并且维护填充水平与阈值，包括全满（full）、将满（almoST full）、将空（almost empty）和全空（empty）。队列管理器还为每个队列提供完全的内存管理，包括空闲池的缓冲分配与回收，以及当某个队列中增加事件时的访问权检查（图2）。多个请求者可以同时为一个或多个队列增加描述符，也能在等待某项服务的多个队列中做出选择。

对于指向相同资源的多个队列，管理器作为可用带宽的仲裁器。此任务不仅是在共享某个资源的各应用之间，也包括一个应用可能必须使能QoS（服务质量）的多个队列之间。

流量管理采用监管与整形机制，测量并控制指定给某个流或一组流的带宽数。监管机制用于控制流量管理器为某个队列增加事件的速率，而整形机制则是流量管理器从队列中去除事件的速率。为了获得最佳的控制，以及管理队列优先权的能力，必须在每个队列基础上实现监管与整形。流量管理器亦根据一个预设的服务算法，将多个队列映射到单一的共享资源。

有了队列和流量管理，就可以提供可靠的端至端QoS。这种方案允许多个路径共享一个资源，而不会对带宽的预订产生负面影响。精细粒度QoS支持SLA（服务水平协议），保证了在每个流量基础上的最小、平均和最大带宽。开发人员可以实现队列水平的流量标记与度量，以防止出现拥塞。拥塞的早期通知使队列管理器能够采用正确的措施，通过向流量资源的反馈，去除对可能丢弃数据包的不必要处理，或理想情况下，能完全避免拥塞。
举例来说，一个基于队列与流量管理的以太网驱动程序能防止任何一个处理器不公平地独占端口带宽。它还能确保带宽分配以及最大的延时约束，而与其它队列状态无关。驱动程序支持对仲裁方法的选择（例如：严格优先级或带权重的轮叫），有助于实现可靠的实时服务，如视频流。最后，多个资源还可以共享以太网端口，而不会对带宽预订产生负面影响。像IP（互联网协议）转发这类任务很容易可靠地实现，而对延时敏感的应用（如音视频的发送）则受益于确定且可靠的端口管理。另外，当用硬件实现了队列和流量管理时，驱动程序几乎无需软件开销，就可以维持端至端的QoS。

2 虚拟化层

早期的多核SoC与初期的网络处理器类似，都将虚拟化资源的全部工作留给了开发人员。应用在某种程度上必须判断出自己在与其它应用共享某个资源。当一个应用使用某个共享资源时，它必须以某种与其它应用共存的方式这样做。操作系统也需要支持虚拟化。

图2.基于硬件的虚拟化卸下了应用处理器的队列管理负担，包括刷新队列状态，维持填充水平和阈值，分配与重新分配缓冲区，以及当应用要访问某队列时，确认其访问权限。

在一个传统架构中，处理器通过一个软件层，管理着自己对共享资源的访问（图3a）。处理器必须知道哪个资源是可用的，以及自己可以使用它们的频率。随着处理数量的增加，资源共享的复杂性也在增长。基于软件虚拟化的一个缺点在于，它为数据包存储以及接下来数据包获取的每个事务都引入了一个开销。这种开销消耗了处理器周期，为代码处理带来了复杂性。它还给虚拟化软件带来了带宽管理和满足预订保证的负担。即使通过工具实现了虚拟化代码的自动化创建，开发者仍然必须在应用交互通过虚拟化代码时，进行查错调试。

图3.（a）随着处理器数量的增长，资源共享的复杂性与开销也在增加
（b）除卸载了队列与流量管理工作以外，资源共享变得对应用透明

2.1 虚拟化增加了开销和复杂性，限制了多核SoC的使用

不过，队列和流量管理是一个相当确定性的过程，可以采用硬件实现。开发人员为某个应用配置一次队列，然后硬件机制就可以完整地卸下队列管理负载，因此将相当多的计算周期还给了应用处理器。动态改变分配的能力使得可以在运行时修改配置，以适应不断变化的工作负载。

在一个采用基于硬件的队列与同步机制的架构中，每个处理器都独立于其它处理器而运行（图3b）。通过资源的虚拟化，共享就对应用透明了。机制会分配每个处理器和每个任务的资源带宽，而每个处理器和任务运行时则像是资源唯一控制方。尽管不同应用实现队列和流量管理的粒度并不相同，但基于硬件的资源虚拟化与共享能显着提高系统的效率。

2.2 基于硬件的虚拟化层去除或加快了软件虚拟化层

虚拟化的卸载显着增加了处理器的效率。在某些情况下，基于硬件的虚拟化完全不需要基于软件的虚拟化，除了在初始配置期间。还有一些情况下，基于硬件的队列与流量管理大大加快了数据路径中虚拟化软件的速度。

2.3 基于硬件的虚拟化层还降低了设计的复杂性，加快了开发进度

因为它不需要开发人员围绕虚拟化层作实现和设计。这种方案简化了设计，加快了上市时间。

2.4 基于硬件的虚拟化层还提高了确定性

由于没有了虚拟化开销，就减少了系统中断的重要来源。于是降低了处理延时，增加了系统的响应能力。
这种方案的另一个好处是简化了调试工作。由于虚拟化和资源共享都是硬件功能，虚拟化层本身就不是开发过程的一部分。但如调试有要求，开发人员仍然拥有对队列的完全访问和控制能力。基于硬件的虚拟化层还增加了可靠性，因为硬件实现的队列和流量管理不易受很多在软件实现中容易出现的问题的影响。例如，如果基于软件的代码处理虚拟化有所折衷，则整个系统就很脆弱。采用基于硬件的实现时，就不存在有受损危险的中心化控制例程。

3 处理器卸载

所支持的队列卸载水平与实现有关。例如，有些SoC可能提供锁定机制，但并不管理队列的全部状态。理想情况下，开发人员想要一个支持不同配置的灵活系统，能直接与软件整合，并尽可能减少为适应SoC而做的软件修改。一个虚拟化机制可能很有效；但是，如果要与传统编程模型有大的变化，则移植应用代码会增加系统成本，延迟上市时间。

实现队列的方式也会影响到系统的性能。例如，队列的位置影响着哪些处理器可以访问这些队列。有些队列必须以内存类型存在，在整个芯片上分布，或者被捆绑到某个资源上。动态分配的队列使开发人员拥有某种灵活性，能恰当地将队列划分给应用和资源。对于采用多只多核SoC的系统，如拥有通过一个系统总线（如PCIe）管理队列的能力，则资源的共享不仅能在同一SoC的不同核心之间，而且能在不同SoC之间。例如，一个处理簇可以共享单个转发数据库。另外，一个多SoC系统可能拥有一个单一的深层数据包检查引擎，而运行在不同SoC上的应用必须访问该引擎。这种多芯片的资源共享能够实现更进一步的系统资源虚拟化。

多芯片架构中最大的设计挑战之一是用某种方式的分区工作，以将资源需求平均地分配给所有处理器。在基于软件的虚拟化中，这个过程可能非常耗时，为设计人员增加了负担，包括高效管理空闲内存池的挑战。另外，软件的任何修改都可能为资源需求带来变化，这就需要开发人员重新划分系统分区。非对称和对称多处理器架构都有很多这类问题。

采用基于硬件的虚拟化时，大多数分区管理任务放在硬件上，而操作系统则处理少量剩余任务。由于采用这种抽象分区，开发人员于做系统修改时，无需对系统做手工的重新分区。这种方案亦卸载了应用与操作系统的一些任务，如管理空闲的内存池。