iot物联网云平台系统设计（专为物联网开发而打造的轻量级hypervisor）

Linux基金会在3月12日发布了一款新的嵌入式hypervisor参考软件，项目的官方名称为ACRN™（发音同”acorn”）。这款hypervisor以实时性和关键安全性为设计出发点，特别为精简嵌入式开发而优化，其中英特尔公司为该项目提供了大部分的设计及代码。

这个项目为各行业的领导者提供了一个参考设计框架, 可以用来构建一个开源的嵌入式hypervisor，尤其适用于物联网领域。

ACRN是专为物联网开发设计的轻量级hypervisor。虽然它“身材很小”，但是“功能强大”。ACRN™提供了一个灵活的，轻量级的hypervisor，以实时性及关键安全性为设计出发点，是一个为精简嵌入式开发而优化的开源的可扩展的参考平台。

如图是ACRN的软件架构图。ACRN是Type-I的hypervisor，其直接运行在物理硬件和固件之上。ACRN通过Service VM来管理各种设备，这样的好处是ACRN hypervisor本身就可以变得既简单又很小。该设计对嵌入式系统尤其重要，特别是如果需要得到功能安全性认证时。另一个好处是客户可以用自己的嵌入式操作系统来充当Service VM，例如用轻量的RTOS来做Service OS，达到实时性要求。

ACRN目前支持Intel的Apollo Lake硬件平台，未来很快将扩展到其他平台。该平台提供Converged Security Engine (CES)，可以用来作为根认证。在固件层，ACRN可以支持PC平台上广泛使用的UEFI固件，另外也支持专门为低延迟性设计的Slimboot固件，ACRN充分利用硬件虚拟化技术，例如CPU虚拟化里的VMX，内存虚拟化中的EPT，设备虚拟化上用于保护设备DMA访问的的VT-d技术。ACRN hypervsior本身运行在VMX的root模式，而其他Guest只能运行在VMX的non-root模式—也被称为Guest模式，Service VM也不例外。与Xen hypervisor不同，XEN里的Dom0是运行在VMX root模式。

目前开源的ACRN hypervisor会创建第一个虚拟机作为Service VM，目前选择Linux作为Service OS。该Serivce OS中包含全部的硬件设备驱动，可以对硬件设备进行访问，另外它还包含I/O Mediator，从而其他的Guest VM可以对硬件设备进行共享访问。

ACRN通过Device Model来要支持多个Guest VM。ACRN的Device Model模块运行在用户态来模拟虚拟硬件平台。该Device Mode经过了全新设计，使用BSD许可证，而不是XEN和KVM使用的的QEMU。因为QEMU对于嵌入式系统来说其过于庞大，包含百万行代码，很难通过工业界的认证。相反，ACRN的Device Mode只有大约2万5千行代码，比较容易通过认证。

ACRN使用工业界标准的Virtio规范来实现I/O虚拟化。在Device Model里包含Virtio的后端驱动(Backend Service)来响应从Guest VM发来的Virtio前端驱动请求(Frontend Driver)，前端驱动和后端驱动使用共享内存环进行通信。

出于性能考量，Service VM除了包含用户态的Device Mediator也包含少量的内存态的Device Mediator。例如声卡设备对延时性要求很高，其Audio Device Mediator是在内存态实现。当然不论用户态或内存态的Device Mediator都符合Virtio规范。

Guest VM从virtual slimboot Loader (SBL)启动，包含Virtio设备驱动和一些legacy设备驱动。Guest OS完全可以重用已有的Linux Virtio驱动，因为ACRN的后端驱动符合标准的Virtio规范。另外，ACRN也实现了很多新的Virtio设备驱动，例如专门为嵌入式系统场景使用的IPU, Audio和CSE设备驱动。另外需要强调的是，ACRN也支持设备的直通配置。

目前ACRN hypervisor支持Linux OS和Android OS，未来将支持更多的OS。对于Android OS，ACRN可以提供一个虚拟化环境支持Android的normal world和trusty world。其中Trusty world用来运行安全性高的用户程序。

同时ACRN也为Guest OS提供硬件的全部的安全功能，例如SEED, Virtual CSE, Virtual SGX，用来支持keystore和enclave。

最后，ACRN hypervisor中还提供了少数对性能要求极高的device model，例如virtual PIC, virtual IOAPIC, virtual LAPCI和virtual MSI。

作为设备hypervisor，ACRN虽然代码量很少但是提供了丰富的功能。ACRN hypervisor只有大约25K行代码，其他的开源hypervisor就远比这个多很多。例如，Xen同样也是Type-I的hypervisor类似的架构设计，Xen总共有大约290K代码，10倍之多于ACRN。KVM的规模还要更大，因为它是Type-II的hypervisor需要和host Linux绑定在一起，大约有17M行代码。

ACRN使用BSD许可证。它满足嵌入式系统生态的需求，因为很多场景下hypervisor需要进行特别定制，甚至替换使用不同的hypervisor。对于私有许可证的hypervisor来说，ACRN为他们提供参考代码，可以被方便集成进OSV或OEM的私有hypervisor。他们可以按照自己的需求，自由使用ACRN的代码。

ACRN在设计之初就把安全性考虑进来，它支持验证启动，从最开始的固件启动直到Guest OS启动。另外ACRN还是先了丰富的I/O设备虚拟化，支持摄像头，声卡，IOC和CSE。

网络虚拟化也同样遵循Virtio网络规范。Guest OS中的Virtio前端驱动不需要做任何改动。在SOS中的Device Model需要实现网络后端服务。利用SOS已有的网络协议栈，虚拟网桥或虚拟交换机，把Guest OS的虚拟网卡和物理网卡进行网络通信。其实现方法和服务器上的虚拟网卡实现没有不同。

该GPU虚拟化的一个特点是，Guest OS中运行原生的GPU驱动，并把非特权指令且又是和性能最相关的资源从Guest中直通给硬件，例如frame buffer和ring buffer。

与此同时，ACRN hypervisor捕获从Guest VM来的特权访问，并把它转给在SOS运行的GPU后端服务。GPU后端服务需要模拟这些指令的访问，并通过在SOS里的真正的GPU物理驱动对硬件进行访问。这种技术有个专门的名称“Mediated Passthrough”。它的性能远好于半虚拟化的实现，例如virtio，但是其代价是软件实较复杂并且需要紧跟硬件的更新而更新。

Intel GPU虚拟化的代码已经进入Linux kernel 4.10版本。在ACRN项目中只需要增加一层对ACRN hypervisor的封装。

I/O Controller (IOC) 被用在车载娱乐系统上，它一端通过串口总线连接到主机CPU上，另一端通过CAN总线连接各种各样控制设备。IOC控制器上定义了很多协议用以和主机CPU进行通信。

ACRN实现了IOC虚拟化。在SOS的Device Model里，IOC后端服务截获Guest OS的IOC信息，然后解析，过滤并模拟这些命令。IOC Mediator把IOC信息分为两类：特权信息是只能被SOS使用的，即只有SOS才有权从IOC物理硬件发送或接收的这类信息，例如发动机转速或电源控制。

另一类IOC信息是非特权信息，Guest OS可以通过虚拟串口进行发送。Device Model通过模拟串口得到信息，然后IOC后端服务过滤信息并发送给物理硬件，如果该信息可被允许发送。反之亦然。