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

引言

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