物联网市场的应用场景日益复杂，越来越多的上网设备需要支持更多的硬件资源、操作系统、软件工具及应用程序，现有的解决方案显然无法为数量庞大的物联网设备提供相应的灵活性，这使开发者们面临巨大的设计压力。虚拟化技术是解决这些问题的关键。不过，现有的虚拟化解决方案并不能满足物联网开发的轻量级和灵活性的特殊要求。为了满足当前物联网市场的发展趋势，Linux基金会推出了开源项目－－－ACRN，
ACRN到底具有哪些强大的功能，它又是怎么实现的？今天我们就从架构到应用对ACRN进行详细分析，让开发者们快速上手使用ACRN进行产品设计。
ACRN是一个专为嵌入式设备设计的hypervisor，包括如下两部分：一套hypervisor的参考软件和架构，通过虚拟机监视器（Virtual Machine Manager）可以在同一个物理硬件上安全地同时运行多个操作系统。另外，它还为设备虚拟化模拟定义了一套参考设计框架，称为“ACRN设备模型”。
ACRN hypervisor是一个Type－I的hypervisor，可以直接运行在物理硬件上，适用于各种物联网和嵌入式设备解决方案。ACRN hypervisor解决了当前数据中心hypervisor和partitioning hypervisor之间存在的差距。ACRN hypervisor设计时把系统分为不同的功能域，并为物联网和嵌入式设备精心挑选的用户操作系统进行共享优化。
汽车应用案例
ACRN hypervisor的一个有趣的案例是用于汽车场景。ACRN hypervisor可以用于构建软件定义驾驶舱（SDC）或者车载娱乐系统（IVE）。作为参考实现，ACRN可以为嵌入式hypervisor厂商的解决方案提供一个很好的基础，以及一套I／O设备虚拟化的参考设计。
在这种场景下，汽车SDC系统由仪表盘（IC）系统、车载信息娱乐系统（IVI）和一个或多个后座娱乐系统（RSE）组成。为了整体系统安全性考虑，每个系统都作为独立的虚拟机运行。
仪表盘系统（IC）用于显示和驾驶员相关的车辆的驾驶操作信息，如：
汽车的速度、燃油、行驶里程和其它驾驶信息；
投影在挡风玻璃上的抬头显示，用以警告缺油或胎压报警；
显示后视摄像头影像和车身的周边摄像头信息，用于辅助停车；
车载娱乐系统（IVI）的功能包括：
导航系统、收音机和其它娱乐系统；
连接到移动设备，可以打电话，播放音乐或者通过语音识别来控制应用程序；
通过手势识别或触控进行交互；
后座娱乐系统（RSE）可以运行：
娱乐系统；
虚拟办公；
连接到前排座椅的IVI系统和移动设备（云连接）；
连接到移动设备，可以打电话，播放音乐或者通过语音识别来控制应用程序；
通过手势识别或触控进行交互；
ACRN hypervisor可以支持Linux＊和Android＊虚拟机作为用户操作系统（UOS），UOS由ACRN hypervisor进行管理。开发者和OEM厂商可以在ACRN hypervisor之上运行自己的虚拟机，以及IC、IVI和RSE VM。Service OS是作为VM0运行（在Xen＊ hypervisor中被称为Dom0，在KVM＊ hypervisor中被称为Host OS），User OS用户操作系统作为VM1运行（也被称为DomU）。
注：Android＊虚拟机的支持将在未来版本发布。
图1显示了一个使用ACRN hypervisor的实例框图。
图1：SOS和UOS运行在ACRN hypervisor之上
从ACRN hypervisor的架构图中可以看到：
ACRN hypervisor直接位于bootloader之上，因而具备快速启动的能力；
部分资源进行partitioning，以确保安全关键性应用和非安全关键业务可以共存在同一平台上；
丰富的I／O设备虚拟化提供在多个VM之间的I／O设备共享，从而提供全面的用户体验；
通过高效的虚拟化，一个SoC可以支持多个操作系统同时运行；
图1中的黄色部分是ACRN项目的软件栈。该架构框图中列出的某些功能还没有完全实现，欢迎社区共同参与开发实现。另外，图中的其他模块来自于别的开源项目，这里仅供参考。
例如，Service OS和Guest Linux来源于https：／／clearlinux．org上的Clear Linux项目，而未来Guest Android的支持将会来自https：／／01．org／android－ia项目。
当前ACRN所支持的功能列表，请参照发布说明。
许可证
ACRN hypervisor和ACRN Device Model软件采用的都是自由许可证的BSD－3－Clause，它允许以“源代码和二进制再次发布和使用，无论是否进行了修改”， 许可证中也注明了完整版权声明和免责声明。
ACRN Device Model， Service OS， and User OS
为了使ACRN hypervisor代码尽可能精悍且高效，用于实现I／O设备共享的device model代码运行在Service OS中而非ACRN Hypervisor。哪些I／O设备被共享以及其实现细节将在下面的pass－through章节具体介绍。
Service OS在所有虚拟机里，以最高优先权运行，以满足那些对时间响应要求很高的需求和系统服务质量的需求（QoS）。具体到Service OS中的任务（task），他们的优先级则有高有低。例如响应User OS请求的回调函数，其运行在Service OS的软件（或者mediator）就会继承User OS的优先级。另外，在Service OS中还有一些在后台运行的任务也是低优先级。
在上述的车载系统示例中，User OS是驾驶控制和车内娱乐的中心枢纽。它能提供收音机和各种娱乐选项、车内空调和通风控制、车辆导航显示等支持。它可以让第三方设备使用USB、蓝牙或者WiFi等连接技术与车载系统进行交互，例如：Android Auto＊ 或者 Apple CarPlay＊， 还能提供许多其它功能。
启动步骤
在图2中，我们展示了在一个采用英特尔架构平台的NUC上使用UEFI验证启动的步骤。
Figure 2 ACRN Hypervisor Boot Flow
启动引导顺序执行如下：
1 UEFI验证和启动ACRN hypervisor和Service OS的引导加载程序；
2 UFEI（或Service OS的引导加载程序）验证并启动Service OS内核；
3 Service OS的内核通过dm－verity验证并且加载ACRN Device Model和虚拟引导加载程序；
4 虚拟引导加载程序启动用户端的验证启动进程；
ACRN Hypervisor架构
ACRN hypervisor是Type 1的虚拟机管理程序，能够直接运行在硬件系统上。它是一个混合的VMM架构，采用一个运行在特权级的Service OS来管理和协调I／O设备的使用。它能支持多个用户虚拟机，其中每个虚拟机都可以运行Linux或者安卓操作系统作为用户操作系统。
在虚拟机内运行的操作系统是与其它虚拟机内的系统或应用程序相互隔离的，从而缩小了潜在的被攻击可能性，最大限度地减小安全隐患。当然由于系统运行在虚拟机内也可能会给其应用程序的运行带来额外的延迟。
图3显示了ACRN hypervisor、车载系统中的Instrumental Cluster （IC） VM和Service VM一起协同工作的架构图。Service OS（SOS）负责包括平台设备在内的大部分设备的管理，并提供I／O的协调功能。某些PCIe设备可以通过VM配置直通给User OS使用。IC应用程序和虚拟机特定的应用程序都运行在SOS中，例如：ACRN device model和ACRN VM管理器。
ACRN hypervisor内还有ACRN虚机管理器，用来收集User OS的运行信息，并控制用户虚拟机的开始、停止和暂停，还能暂停或者恢复执行单个虚拟CPU。
图3 ACRN Hypervisor 架构图
ACRN hypervisor采用了英特尔虚拟化技术（Intel VT），其运行在虚拟机扩展模式（VMX）的root模式下，也称为主机模式或VMM模式。其他所有的用户虚拟机包括UOS和SOS都运行在VMX non－root模式或guest模式下。（以下为了简略，我们将继续使用术语VMM模式和guest模式）。
VMM模式下有4种权限的ring模式，但ACRN hypervisor仅在ring 0的特权模式下运行，其余ring 1－3并未使用。运行在guest模式下的用户系统（包括SOS和UOS）也有自己的4个ring模式（ring 0－3）。用户系统的内核运行在guest模式下的ring 0，而用户系统的应用程序则在guest模式下运行于ring 3（ring 1和ring 2一般不被商业操作系统所使用）。
图4 VMX 简介
如图4所示，VMM模式和guest模式通过VM Exit和VM Entry进行切换。当引导加载程序将控制权交给ACRN hypervisor时，处理器还未启动VMX模式。ACRN hypervisor首先需要通过VMXON指令启用VMX模式。启用VMX后，处理器处于VMM模式，它可以通过VM resume指令进入guest模式（或者通过第一次VM launch指令），然后可以通过处理器的VM exit事件回到VMM模式。一般处理器会在响应某些指令和事件时发生VM exit。
在guest模式下，处理器的执行是由一个虚拟机控制结构（VMCS）所控制的。VMCS包含了虚机状态（在VM Entry时加载并在VM Exit时保存），主机状态（在VM exit时加载），以及虚机的控制执行。ACRN hypervisor为每个虚拟CPU创建了一个VMCS数据结构，并使用该VMCS来控制运行在guest模式下处理器的行为。
当虚机执行到一个敏感指令时，就会触发一次定义在VMCS配置中的VM exit事件。当VM exit发生后，系统的控制权就交给了ACRN hypervisor。ACRN hypervisor会模拟虚机的指令（如果VM exit的原因是由于指令权限问题），然后恢复虚机继续执行它的下一条指令，或者根据VM exit的原因进行相关处理（例如，一个虚机的存储页面需要建立映射关系），然后恢复虚机重新执行该条指令。
需要注意的是用于VMM模式的地址空间和用于guest模式的地址空间是不同的。guest模式和VMM模式下使用不同的内存映射表，因此虚机是无法访问ACRN hypervisor的。ACRN hypervisor使用EPT来映射虚机地址，虚机页表会将虚机的线性地址映射到虚机的物理地址， EPT表则将虚机的物理地址映射到机器物理地址或主机物理地址（HPA）。
ACRN Device Model Architecture
因为系统设备可能需要在不同的虚机之间被共享，虚机内应用程序（和操作系统）要对这些共享设备进行访问就需要借助设备模拟。一般来说，设备模拟有三种架构：
·第一种架构被称为hypervisor中的设备模拟，这是在VMware＊工作站产品（一个基于操作系统的hypervisor）中实现的设备模拟方式。在这种方式中，hypervisor负责模拟需要在各个虚机操作系统之间共享的常见设备，其中包括：虚拟磁盘、虚拟网络适配器和其它必要的平台资源。
·第二种架构称为用户空间的设备模拟。顾名思义，不是将设备模拟的实现嵌入到hypervisor中，而是将其放在一个用户空间的应用程序中实现。比如被各种独立的hypervisor所使用的QEMU就提供了此类的设备模拟方式。这种架构的优势在于设备模拟的实现不依赖于hypervisor，所以其它hypervisor可以重用改实现。甚至它还可以做任意设备的模拟，而不必担心其功能的实现会影响hypervisor（其在特权模式下运行）。
·第三种架构则是从基于hypervisor的设备模拟改变而来的半虚拟化驱动程序。该架构一开始是在XEN项目中引入的，其中hypervisor提供物理设备驱动，每个虚机操作系统则需要安装一个与能与物理驱动配合使用的hypervisor感知的驱动程序。
在以上讨论的设备模拟架构中，共享设备都需要付出代价。因为不管设备模拟是在hypervisor中，还是在每个虚机内的用户空间中，都存在相应的系统开销。不过只要系统设备需要被多个虚机操作系统共享，这种开销就是值得的。反之如果设备不需要被共享，那么就可以使用更有效的方法来访问设备，例如使用“直通”。
看完以上的分析，你是否对ACRN有了更深入的了解？也是否有更多问题急需解答？ 不用着急，我们将在下期中继续讲解各种技术细节，例如ACRN设备模块架构、设备pass through， ACRN I／O mediator， Virtio框架结构等一一为你展示。
