物联网市场的应用于场景日益简单，更加多的网际网路设备必须反对更好的硬件资源、操作系统、软件工具及应用程序，现有的解决方案似乎无法为数量可观的物联网设备获取适当的灵活性，这使开发者们面对极大的设计压力。虚拟化技术是解决问题这些问题的关键。

不过，现有的虚拟化解决方案并无法符合物联网研发的轻量级和灵活性的特殊要求。为了符合当前物联网市场的发展趋势，Linux基金会发售了开源项目－－－ACRN，ACRN究竟具备哪些强劲的功能，它又是怎么构建的？今天我们就从架构到应用于对ACRN展开详细分析，让开发者们较慢上手用于ACRN展开产品设计。ACRN是一个专为嵌入式设备设计的hypervisor，还包括如下两部分：一套hypervisor的参照软件和架构，通过虚拟机监视器（VirtualMachineManager）可以在同一个物理硬件上安全性地同时运营多个操作系统。另外，它还为设备虚拟化仿真定义了一套参照设计框架，称作“ACRN设备模型”。

ACRNhypervisor是一个Type－I的hypervisor，可以必要运营在物理硬件上，限于于各种物联网和嵌入式设备解决方案。ACRNhypervisor解决问题了当前数据中心hypervisor和partitioninghypervisor之间不存在的差距。ACRNhypervisor设计时把系统分成有所不同的功能域，并为物联网和嵌入式设备精心挑选出的用户操作系统展开分享优化。

汽车应用于案例ACRNhypervisor的一个有意思的案例是用作汽车场景。ACRNhypervisor可以用作建构软件定义驾驶舱（SDC）或者车载娱乐系统（IVE）。作为参照构建，ACRN可以为嵌入式hypervisor厂商的解决方案获取一个很好的基础，以及一套I／O设备虚拟化的参照设计。在这种场景下，汽车SDC系统由仪表盘（IC）系统、车载信息娱乐系统（IVI）和一个或多个后座娱乐系统（RSE）构成。

为了整体系统安全性考虑到，每个系统都作为独立国家的虚拟机运营。仪表盘系统（IC）用作表明和驾驶员涉及的车辆的驾驶员操作者信息，如：汽车的速度、燃油、行经里程和其它驾驶员信息；投影在挡风玻璃上的浮现表明，借以警告缺油或胎压报警；表明后视摄像头影像和车身的周边摄像头信息，用作辅助行驶；车载娱乐系统（IVI）的功能还包括：导航系统、收音机和其它娱乐系统；相连到移动设备，可以打电话，播出音乐或者通过语音辨识来控制应用程序；通过手势辨识或触控展开交互；后座娱乐系统（RSE）可以运营：娱乐系统；虚拟世界办公；相连到后排座椅的IVI系统和移动设备（云相连）；相连到移动设备，可以打电话，播出音乐或者通过语音辨识来控制应用程序；通过手势辨识或触控展开交互；ACRNhypervisor可以反对Linux＊和Android＊虚拟机作为用户操作系统（UOS），UOS由ACRNhypervisor展开管理。开发者和OEM厂商可以在ACRNhypervisor之上运营自己的虚拟机，以及IC、IVI和RSEVM。

ServiceOS是作为VM0运营（在Xen＊hypervisor中被称作Dom0，在KVM＊hypervisor中被称作HostOS），UserOS用户操作系统作为VM1运营（也被称作DomU）。录：Android＊虚拟机的反对将在未来版本公布。图1表明了一个用于ACRNhypervisor的实例框图。图1：SOS和UOS运营在ACRNhypervisor之上从ACRNhypervisor的架构图中可以看见：ACRNhypervisor必要坐落于bootloader之上，因而不具备较慢启动的能力；部分资源展开partitioning，以确保安全关键性应用于和非安全性关键业务可以共计不存在同一平台上；非常丰富的I／O设备虚拟化获取在多个VM之间的I／O设备分享，从而获取全面的用户体验；通过高效的虚拟化，一个SoC可以反对多个操作系统同时运营；图1中的黄色部分是ACRN项目的软件栈。

该架构框图中所列的某些功能还没几乎构建，青睐社区联合参予研发构建。另外，图中的其他模块来自于别的开源项目，这里仅供参考。

例如，ServiceOS和GuestLinux源于https：／／clearlinux．org上的ClearLinux项目，而未来GuestAndroid的反对将不会来自https：／／01．org／android－ia项目。当前ACRN所反对的功能列表，请求参考公布解释。许可证ACRNhypervisor和ACRNDeviceModel软件使用的都是权利许可证的BSD－3－Clause，它容许以“源代码和二进制再度公布和用于，无论否展开了改动”，许可证中也标明了原始版权声明和正当理由声明。ACRNDeviceModel，ServiceOS，andUserOS为了使ACRNhypervisor代码尽量精悍且高效，用作构建I／O设备分享的devicemodel代码运行在ServiceOS中而非ACRNHypervisor。

哪些I／O设备被分享以及其构建细节将在下面的pass－through章节明确讲解。ServiceOS在所有虚拟机里，以最低优先权运营，以符合那些对时间号召拒绝很高的市场需求和系统服务质量的市场需求（QoS）。明确到ServiceOS中的任务（task），他们的优先级则有高有低。

例如号召UserOS催促的消息传递函数，其运营在ServiceOS的软件（或者mediator）就不会承继UserOS的优先级。另外，在ServiceOS中还有一些在后台运营的任务也是低优先级。在上述的车载系统示例中，UserOS是驾驶员掌控和车内娱乐的中心枢纽。它能获取收音机和各种娱乐选项、车内空调和通风掌控、车辆导航系统表明等反对。

它可以让第三方设备用于USB、蓝牙或者WiFi等相连技术与车载系统展开交互，例如：AndroidAuto＊或者AppleCarPlay＊，还能获取许多其它功能。启动步骤在图2中，我们展出了在一个使用英特尔架构平台的NUC上用于UEFI检验启动的步骤。

Figure2ACRNHypervisorBootFlow启动引领顺序继续执行如下：1UEFI检验和启动ACRNhypervisor和ServiceOS的引领读取程序；2UFEI（或ServiceOS的引领读取程序）检验并启动ServiceOS内核；3ServiceOS的内核通过dm－verity检验并且读取ACRNDeviceModel和虚拟世界引领读取程序；4虚拟世界引领读取程序启动用户端的检验启动进程；ACRNHypervisor架构ACRNhypervisor是Type1的虚拟机管理程序，需要必要运营在硬件系统上。它是一个混合的VMM架构，使用一个运营在特权级的ServiceOS来管理和协商I／O设备的用于。它能反对多个用户虚拟机，其中每个虚拟机都可以运营Linux或者安卓操作系统作为用户操作系统。在虚拟机内运营的操作系统是与其它虚拟机内的系统或应用程序互相隔绝的，从而增大了潜在的被反击可能性，最大限度地增大安全隐患。

当然由于系统运营在虚拟机内也可能会给其应用程序的运营带给额外的延后。图3表明了ACRNhypervisor、车载系统中的InstrumentalCluster（IC）VM和ServiceVM一起协同工作的架构图。

ServiceOS（SOS）负责管理还包括平台设备在内的大部分设备的管理，并获取I／O的协商功能。某些PCIe设备可以通过VM配备直通给UserOS用于。IC应用程序和虚拟机特定的应用程序都运营在SOS中，例如：ACRNdevicemodel和ACRNVM管理器。ACRNhypervisor内还有ACRN虚机管理器，用来搜集UserOS的运营信息，并掌控用户虚拟机的开始、暂停和停止，还能停止或者完全恢复继续执行单个虚拟世界CPU。

图3ACRNHypervisor架构图ACRNhypervisor使用了英特尔虚拟化技术（IntelVT），其运营在虚拟机拓展模式（VMX）的root模式下，也称作主机模式或VMM模式。其他所有的用户虚拟机还包括UOS和SOS都运营在VMXnon－root模式或guest模式下。（以下为了简略，我们将之后用于术语VMM模式和guest模式）。

VMM模式上有4种权限的ring模式，但ACRNhypervisor仅有在ring0的特权模式下运营，其余ring1－3未用于。运营在guest模式下的用户系统（还包括SOS和UOS）也有自己的4个ring模式（ring0－3）。用户系统的内核运营在guest模式下的ring0，而用户系统的应用程序则在guest模式下运营于ring3（ring1和ring2一般不被商业操作系统所用于）。

图4VMX概述如图4右图，VMM模式和guest模式通过VMExit和VMEntry展开转换。当引领读取程序将控制权转交ACRNhypervisor时，处理器还并未启动VMX模式。ACRNhypervisor首先必须通过VMXON指令落成VMX模式。落成VMX后，处理器正处于VMM模式，它可以通过VMresume指令转入guest模式（或者通过第一次VMlaunch指令），然后可以通过处理器的VMexit事件返回VMM模式。

一般处理器不会在号召某些指令和事件时再次发生VMexit。在guest模式下，处理器的继续执行是由一个虚拟机控制结构（VMCS）所掌控的。VMCS包括了元神机状态（在VMEntry时读取并在VMExit时留存），主机状态（在VMexit时读取），以及虚机的掌控继续执行。

ACRNhypervisor为每个虚拟世界CPU创立了一个VMCS数据结构，并用于该VMCS来掌控运营在guest模式下处理器的不道德。当虚机继续执行到一个脆弱指令时，就不会启动时一次定义在VMCS配备中的VMexit事件。

当VMexit再次发生后，系统的控制权就转交了ACRNhypervisor。ACRNhypervisor不会仿真虚机的指令（如果VMexit的原因是由于指令权限问题），然后完全恢复虚机继续执行它的下一条指令，或者根据VMexit的原因展开涉及处置（例如，一个虚机的存储页面必须创建同构关系），然后完全恢复虚机新的继续执行该条指令。

必须留意的是用作VMM模式的地址空间和用作guest模式的地址空间是有所不同的。guest模式和VMM模式下用于有所不同的内存同构表格，因此虚机是无法访问ACRNhypervisor的。

ACRNhypervisor用于EPT来同构虚机地址，虚机页表会将虚机的线性地址映射到虚机的物理地址，EPT表则将虚机的物理地址映射到机器物理地址或主机物理地址（HPA）。ACRNDeviceModelArchitecture因为系统设备有可能必须在有所不同的虚机之间被分享，虚机内应用程序（和操作系统）要对这些分享设备展开采访就必须利用设备仿真。一般来说，设备仿真有三种架构：·第一种架构被称作hypervisor中的设备仿真，这是在VMware＊工作站产品（一个基于操作系统的hypervisor）中构建的设备仿真方式。在这种方式中，hypervisor负责管理仿真必须在各个虚机操作系统之间分享的少见设备，其中还包括：虚拟世界磁盘、虚拟世界网络适配器和其它适当的平台资源。

·第二种架构称作用户空间的设备仿真。顾名思义，不是将设备仿真的构建映射到hypervisor中，而是将其放到一个用户空间的应用程序中构建。

比如被各种独立国家的hypervisor所用于的QEMU就获取了此类的设备仿真方式。这种架构的优势在于设备仿真的构建不依赖hypervisor，所以其它hypervisor可以器重改为构建。

甚至它还可以做到给定设备的仿真，而不用担忧其功能的构建不会影响hypervisor（其在特权模式下运营）。·第三种架构则就是指基于hypervisor的设备仿真转变而来的半虚拟化驱动程序。

该架构一开始是在XEN项目中引进的，其中hypervisor获取物理设备驱动，每个虚机操作系统则必须加装一个与能与物理驱动因应用于的hypervisor感官的驱动程序。在以上辩论的设备仿真架构中，分享设备都必须付出代价。因为不管设备仿真是在hypervisor中，还是在每个虚机内的用户空间中，都不存在适当的系统支出。

不过只要系统设备必须被多个虚机操作系统分享，这种支出就是有一点的。反之如果设备不必须被分享，那么就可以用于更加有效地的方法来采访设备，例如用于“直通”。看完了以上的分析，你否对ACRN有了更加了解的理解？也否有更加多问题急需答案？不必生气，我们将在下期中之后介绍各种技术细节，例如ACRN设备模块架构、设备passthrough，ACRNI／Omediator，Virtio框架结构等一一为你展出。

本文来源：beat·365-www.genesis358.com