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

4 带宽保证

对一个资源的控制亦扩展了一只处理器可以接受的最大分配限度，解决了接收端的处理瓶颈问题。例如，对于很多通信、音视频、数据采集以及测试与测量应用，接收处理器都有预期或可以处理的最大传输数据速率。在这些情况下，即使外设拥有更多的能力（因为其它处理器当前未使用它们的分配额），应用也不希望队列以更快的速率刷新，因为这种刷新可能超出接收处理器的能力，造成数据损失。

很多开发人员在设计时会采用最差情况方法；他们要确认有足够的容量支持最差情况的负载。但是，在典型工作条件下，这种方法无法用到全部的资源容量。例如，一个典型的轮转仲裁算法仅支持最低的配额。如果系统对某个资源有多达10个请求方，则每个请求方总是可以期望拥有至少10%的带宽。然而，如果仅有一个请求方活动，则该请求方可以获得100%的带宽。

虚拟与透明的资源分配方法意味着一个应用并不知道自己可能获得多少带宽。对于接收端存在瓶颈的应用，为某个资源设定最大配额的能力对系统的稳定非常重要。这个最大值使开发人员能够控制每个应用的资源带宽（无论采用了何种分配算法），以防止淹没接收端的处理器，并且防止了数据损失。开发人员还拥有用标准机制去管理拥塞的选择，如IEEE 802.1Qav或802.1Qau。

5 系统稳定性

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

基于硬件的队列管理能在系统的各个部件之间提供保护。最基本的故障隔离方式是阻止对分配给其它应用的内存与资源带宽的访问。为了使虚拟化资源对应用完全透明，队列和流量管理器必须只对损坏的应用采取行动。换句话说，必须要将应用与其它应用的活动屏蔽开来，并且要适应其它应用的故障，以维持稳定性。就其特性而言，专用队列可隔离故障，防止其它处理器和应用受到影响。这类队列还有利于有效的错误恢复；专用队列可以完全地清除错误，而不会使其它应用的数据受到损失。

一个队列与流量管理控制器可以实现对非法资源访问的多级响应。最简单的响应是阻止访问，并给应用生成一个警报，通常是通过一个中断。这个警报告诉应用，它试图做了一些不应做的事。第二种方法是由开发人员记录下使用的违背情况，帮助在现场查错。队列与流量控制器亦必须能够通过触发一个复位，并重新初始化一个可能损坏的应用，逐步升级其响应。理想情况下，开发人员可以创建一个控制此响应的策略。例如，开发人员可以设定一个阈值，如果某个应用做了三次非法访问，就认为它是一个已损坏的应用，必须重新启动。

6 部分虚拟化

当一系列事务必须依次发生时，这种要求就成为了一个阻塞实例，因为其它请求方必须等待此事务的完成，然后才能获得资源的控制权。考虑一个典型的SATA（串行先进技术连接）事务，此时首先要配置SATA端口，然后执行一个指令序列。与数据包都是单个事件的以太网端口不同，SATA端口必须锁定给某个应用，直到事务完成时为止；否则，两个应用会相互覆盖，致使谁也无法完成自己的任务。

图4.（a）硬件实施的虚拟化在有完全宽带管理的SOC中也能实现资源分配
（b）这种方案能够在整个系统上高效地共享资源

尽管各个应用无法完全共享支持这种事务特性的资源，但对配额可以做部分虚拟化。首先，等待使用资源的应用必须确认端口空闲可用，然后在使用期间锁定端口。对锁定的支持要求在操作系统中有一个薄的软件层，这样就能相互通信，看哪个应用拥有对锁的控制权。不过，硬件的使用可以管理锁，并加快锁的获得速度。必须用硬件实现锁的获取，从而为资源提供一种失效恢复机制；或者，也可以用一个加锁处理器去锁定资源。

根据应用情况，系统必须支持可以完全虚拟化的共享资源，以及需要锁定的共享资源。例如，一片SoC可以提供一个不共享的SATA端口，但只有一个处理器可以使用它，而资源的共享必须在软件中实现。另外通过对可锁定资源的支持，SoC中的核心仍能够以一种对所有应用透明的方式，共享资源，具有失效恢复的可靠性。

多核架构的一个重要方面是易于集成。将多个处理器做到一只芯片上的能力，需要应用软件的直接迁移；否则，开发人员还不如去设计一个新的系统。

在确定迁移到虚拟化架构是否方便时，必须考虑一系列因素。例如，架构必须支持多操作系统，因为根据需要支持的应用情况，多处理器经常会在多个核心上使用多个操作系统。仅支持一个操作系统的多核架构会使开发人员被迫采用该操作系统，然后将所有代码移植到它上面。而支持多个操作系统时，一片多核SoC就简化了代码迁移工作。

另外，还需要考虑到QoS问题，因为各个应用有不同的带宽需求。延时敏感型应用（如视频流）需要实时访问共享资源，而数据型的应用（如内容下载）可以容忍延迟，充分利用未使用的带宽。为不同带宽需求提供服务的能力使开发人员能够在相同的处理簇下整合异质的应用。

还要考虑架构是否包含了透明的资源共享，因为透明性能让开发人员同时迁移支持虚拟化的应用以及不支持虚拟化的应用。另外一个方面是去除软件虚拟化层。虽然在做SoC之间的移植时，某些代码的重写是必要的，但对很多应用来说，当转向采用硬件资源共享的SoC时，大多数的变动并不是修改软件，而是消除软件虚拟化层。去掉这一层可简化系统设计与查错工作，增加了系统的效率。对于制造商已取得虚拟化代码许可的情况，去掉此层还可以降低系统成本。

还有一个要考虑的因素，即架构是否整合了系统资源。当一个系统采用多只芯片和操作系统时，每个都有自己的存储资源。通过资源的硬件管理，所有任务都可以共享对资源的访问。例如，一块硬盘或一个以太网端口可以服务于整个系统（甚至跨各个SoC），而不是像传统架构那样需要多块硬盘。这种方案可节省设备成本，降低系统部件的总数。

SoC之间的通信也很重要。各个应用可以通过一个大带宽系统总线（如PCIe）共享资源，从而实现了SoC之间的共享。传统架构会给每个处理器分配一个固定带宽，这种方法限制了各核之间的有效QoS管理，难以超额申请（图4a）。采用基于硬件的虚拟化时，即使在SoC之间，资源的分配也是灵活的（图4b）。通过速率监管、流量整形，以及队列仲裁，反映并平衡着每个处理器与应用的需求，从而能够实现全带宽管理。同样，这种方案还能够获得资源（如一块硬盘或一个安全引擎）在整个系统上的有效共享，而不仅是一只处理器。

另外还应考虑的是处理器之间的通信，因为多处理器系统经常要在各处理器之间传输相当多的数据。队列管理机制为SoC上各处理器之间以及多个SoC之间的通信提供了一种简单而有效的加速方法。