上篇文章汽车电子架构演进五-三域融合之“三国杀”随着EEA汽车电子电气架构的发展关于域融合的话题也比较多其中除了硬件芯片集成的发展另一方面就是Hypervisor虚拟机。目前在分散的三域中有很多OS例如汽车仪表系统与信息娱乐系统汽车仪表系统与动力系统密切相关要求具有高实时性、高可靠性和强安全性如QNX操作系统而信息娱乐系统主要为车内人机交互提供控制平台追求多样化的应用与服务如Linux和Android操作系统。所以在未来集中式架构中不同处理优先级和不同安全等级要求的应用程序将被高度集成在中央计算单元中软件复杂度比传统车载软件要超出1-2个量级对汽车安全性的要求也大大提升。虚拟化Hypervisor解决方案提供了在同一硬件平台上承载异构操作系统的灵活性同时实现了良好的高可靠性和故障控制机制, 以保证关键任务、硬实时应用程序和一般用途、不受信任的应用程序之间的安全隔离实现了车载计算单元整合与算力共享。之前有一篇文章电源管理入门-20 Hypervisor中的电源管理基本把Hypervisor讲清楚了这里我们再回顾下其基础知识然后再进行补充一下在汽车域融合中的应用。1. Hypervisor介绍1.1 Hypervisor分类虚拟机管理器又称Hypervisor 也称为虚拟机监控程序VMM,其处于SoC 硬件平台之上将实体资源如CPU、内存、存储空间、网络适配器、外设等) 转换为虚拟资源按需分配给每个虚拟机允许它们独立地访问已授权的虚拟资源。Hypervisor实现了硬件资源的整合和隔离使应用程序既能共享CPU等物理硬件也能依托不同的内核环境和驱动运行从而满足现代复杂软硬件系统多元化应用场景需求。目前通常使用两种类型的管理程序Type 1:裸机虚拟机管理程序一种在硬件上本机运行的管理程序。Type 2:托管虚拟机监控程序此类型的虚拟机监控程序必须由另一个操作系统托管并且仅负责使用主机操作系统可用的资源来虚拟化客户操作系统。|类型|优点|缺点|| — | — | — ||Type 1|不必预先加载底层操作系统直接访问底层硬件而无需其他软件(例如操作系统和设备驱动程序)速度快直接在物理硬件上运行相对较安全因为裸机虚拟机管理程序可避免操作系统通常存在的安全问题和漏洞。这可确保每个访客VM与恶意软件和活动保持逻辑隔离。|移植成本较高||Type 2|通用性强好移植|底层操作系统的存在会引入不可避免的延迟因为所有该管理程序的活动和每个VM的工作都必须通过主机操作系统。主机操作系统中的任何安全问题或漏洞都可能会危及在其上运行的所有虚拟机。因此Type2管理程序通常不用于数据中心计算并且仅用于客户端或最终用户系统其中性能和安全性较少受到关注。|我们在大SoC域融合场景下使用的就是Type 1的模式Hypervisor直接运行是硬件上向上层OS提供服务。VMM首先需要对CPU、内存、中断等资源进行管理并提供对应虚拟化功能按照I/O设备驱动的布局又可以分为Hypervisor模型和混合模型Hypervisor模型VMM设备驱动提供物理设备驱动管理并向上提供服务混合模型VMM只提供必要的CPU资源管理由Guest Server OS提供设备管理和虚拟化服务。参考Hypervisor模型QNX参考混合模型代表有XenIntel的Acrn以及国内的minos和bao-hypervisor1.2 ARM上的位置Type 1的Hypervisor向上面的OS提供服务但是OS之下是各种固件那么Hypervisor在这一堆固件中的位置在哪里这涉及到具体的代码实现。首先参考上图中ARM异常等级及安全世界和非安全世界的划分EL0非安全态的Apps安全态的Trusted AppsEL0是无特权模式所有APP应用都在EL0。EL1非安全态的Normal world OS安全态的Trusted OS EL1是一个特权模式能够执行一些特权指令用于运行各类操作系统EL2Hypervisor虚拟层EL3Secure MonitorArm trusted firmware安全固件EL3具有最高管理权限负责安全监测和Secure World和Normal World之间的切换。EL0 EL1: SVC (system call)EL1 EL2: HVC (hypervisor call)EL2 EL3: SMC (secure monitor call)在ATFARM底层固件中Hypervisor的位置如下可见Hypervisor在BL31ATF之上所以OS的SMC系统调用请求是先陷入Hypervisor如果Hypervisor处理不了再去BL31的。2. 汽车中的应用为什么汽车中迫切需求Hypervisor汽车上有三个域车身域、座舱域、智驾域。也就是说有三个OS运行在复杂的SoC上。在域融合的同时要保证关键业务的安全可靠也要考虑应用生态的可持续性兼容这就需要有资源隔离技术来支撑在同一 SOC 上切分资源可并发运行多种操作系统保障互不干扰。基于安全和资源隔离的需求需要Hypervisor。2.1 资源分配隔离Hypervisor处于 SoC 硬件平台之上将实体资源如 CPU、内存、存储空间、网络适配器、外设等 ) 转换为虚拟资源按需分配给每个虚拟机允许它们独立地访问已授权的虚拟资源。Hypervisor 实现了硬件资源的整合和隔离使应用程序既能共享 CPU 等物理硬件也能依托不同的内核环境和驱动运行从而满足汽车领域多元化应用场景需求。资源隔离技术有很多为什么是Hypervisor资源隔离技术有多种从硬件底层逐层向上包括硬件隔离、虚拟化隔离、容器隔离、进程隔离等。硬件隔离的隔离性最好单隔离域的性能、安全可靠性最好但灵活性、可配置性差不能实现硬件共享导致整个系统的资源利用率差不能充分达到软件定义汽车的目标。容器隔离、进程隔离可以更轻量级地实现业务隔离但还是在同一个操作系统内存在着资源干扰、相互安全攻击的隐患并且无法支持异构操作系统业务域融合影响传统业务继承不利于生态发展。在众多的资源隔离技术中虚拟化是安全可靠、弹性灵活的优选方案是软件定义汽车的重要支撑技术。Hypervisor的特点隔离VM之间资源隔离资源共享VM间资源更新负载均衡根据VM对资源使用情况动态调配供给高可用VM与硬件解绑硬件出问题时VM可以迅速迁移到其他硬件弹性伸缩根据业务情况开关不同的VM这里汽车上主要使用隔离和资源共享功能。在汽车领域Hypervisior 主要完成以下任务CPU虚拟化为虚拟机提供 VCPU 资源和运行环境内存虚拟化负责为其自身和虚拟机分配和管理硬件内存资源中断虚拟化发生中断和异常时按需将中断和异常路由到虚拟机进行处理虚拟机设备模拟根据需求创建虚拟机可以访问的虚拟硬件组件硬件支持 BSP提供 Hypervisor 在 SoC上运行的板级支持包如串口驱动虚拟机资源配置对虚拟机的 CPU内存IO 外设等资源进行配置和管理虚拟机通信为虚拟机提供 IPC共享内存等通信机制。虚拟机调度为虚拟机提供优先级和时间片等调度算法虚拟机生命周期管理创建启动和停止虚拟机虚拟机调测服务提供控制台日志等调试功能2.1.1 CPU虚拟化VM管理VM都是运行在CPU上的所以Hypervisor对vCPU的管理就可以管理VM的生命周期了。一个VM在Hypervisor中类似一个进程有自己的页表空间和IPA空间其可以有别的VM创建也可系统启动静态配置拉起。vCPU的管理首先就是虚拟CPU和物理CPU的绑定策略。对于车控这种安全要求高的系统在Hypervisor上尽量分配静态的资源例如进行绑核处理这样就有了专用核硬件保证资源专用充足从而实现实时性需求。Hypervisor的陷入管理: VM主动HVC、SMC trap进入Hypervisor或者异常缺页、特权寄存器访问的情况陷入vCPU上下文主要就是CPU的寄存器例如正常我们在执行WFI指令时会使CPU进入一个低功耗的状态但是对于HOST OS来说如果让CPU真正进入低功耗状态显然会影响其他VM的运行。如果我们配置了HCR_EL2.TWI1时那么Guest OS在执行WFI时就会触发EL2的异常然后陷入Hypervisor那么此时Hypervisor就可以将对应VCPU所处的线程调出出去将CPU让给其他的VCPU线程使用。2.1.2 内存虚拟化内存虚拟化的目的是给虚拟客户机操作系统提供一个从0开始的连续的地址空间同时在多个客户机之间实现隔离与调度。arm主要通过Stage 2转换来提供对内存虚拟化的支持其允许Hypervisor控制虚拟机的内存视图而在这之前则是使用及其复杂的影子页表技术来实现。Stage 2转换可以控制虚拟机是否可以访问特定的某一块物理内存以及该内存块出现在虚拟机内存空间的位置。这种能力对于虚拟机的隔离和沙箱功能来说至关重要。这使得虚拟机只能看到分配给它自己的物理内存。为了支持Stage 2 转换 需要增加一个页表我们称之为Stage 2页表。操作系统控制的页表转换称之为stage 1转换负责将虚拟机视角的虚拟地址转换为虚拟机视角的物理地址。而stage 2页表由Hypervisor控制负责将虚拟机视角的物理地址转换为真实的物理地址。虚拟机视角的物理地址在Armv8中有特定的词描述叫中间物理地址(intermediate Physical Address, IPA)。stage 2转换表的格式和stage 1的类似但也有些属性的处理不太一样例如,判断内存类型 是normal 还是 device的信息被直接编码进了表里而不是通过查询MAIR_ELx寄存器。2.1.3 中断虚拟化中断从设备发送到CPU需要经过中断控制器现代x86架构采用的中断控制器被称为APIC**(Advanced Programmable Interrupt Controller)。APIC是伴随多核处理器产生的所有的核共用一个**I/O APIC用于统一接收来自外部I/O设备的中断而后根据软件的设定格式化出一条包含该中断所有信息的Interrupt Message发送给对应的CPU。每个核有一个Local APIC用于接收来自I/O APIC的Interrupt Message内部的时钟和温控中断以及来自其他核的中断也就是IPI(Inter-Processor Interrupt)。在虚拟化环境中VMM需要为guest VM展现一个与物理中断架构类似的虚拟中断架构。每个虚拟CPU都对应一个虚拟的Local APIC多个虚拟CPU共享一个虚拟的I/O APIC。和虚拟CPU一样虚拟的Local APIC和虚拟的I/O APIC都是VMM维护的软件实体以下统称虚拟中断控制器。中断虚拟化的主要任务就是实现下图描述的虚拟中断架构包括虚拟中断控制器的创建中断采集和中断注入。2.1.4 IO虚拟化I/O设备作为一种外部设备其虚拟化的实现相较于前面的CPU虚拟化及内存虚拟化有些不同其目前主要有以下四种虚拟化方案。1、 设备模拟在虚拟机监控器中模拟具体的I/O设备的特性例如qemu。在KVM和qemu的组合中通过Hypervisor捕获Guest OS的I/O请求交给用户空间的qemu进行模拟然后将结果再通过Hypervisor传递给Guest OS。这种方式能够提供非常好的兼容性但是性能太差同时模拟设备的功能特性支持不够多。2、 前后端驱动接口在Hypervisor和Guest OS之间定义一种权限的适用于虚拟机的交互接口比如virtio技术。这个方案相较于设备模拟在性能上有所提高但是兼容性较差而且在高I/O负载场景后端驱动的CPU占用较高。3、 设备直接分配将一个物理设备直接分配给Guest OS使用。此方式的性能显而易见要比上面两种好很多但是需要硬件设备支持且无法共享和动态迁移。4、 设备共享分配此方式是设备直接分配的一个扩展其主要就是让一个物理设备可以支持多个虚拟机功能接口将不同的接口地址独立分配给不同的Guest OS使用。如SR-IOV协议。2.2 OS间通信Hypervisor中有很多技术例如CPU 虚拟化和节能降耗技术、IO 设备虚拟化、实时性技术、安全和可靠性技术等大家可以自己查资料去学习特别是参考国内的minosbao-hypervisor开源软件去学习修改使用大家懂的。这里主要介绍下多OS的通信技术后面在介绍多OS电源管理时会用到。Hypervisor虚拟化管理程序是一种软件或硬件层面的虚拟化技术用于在物理计算机上运行多个虚拟操作系统OS。Hypervisor需要提供一种有效的机制以便不同虚拟机VM之间以及虚拟机与宿主机host之间进行通信。以下是几种常见的Hypervisor的OS间通信机制虚拟网络Hypervisor可以创建虚拟网络为虚拟机提供网络连接和通信功能。虚拟网络允许虚拟机之间进行网络通信就像它们连接在同一物理网络上一样。这种通信机制基于网络协议和虚拟网络设备的实现。共享内存Hypervisor可以在物理内存中创建共享区域允许不同的虚拟机共享内存数据。通过在共享内存区域中读取和写入数据虚拟机可以进行相互通信。这种通信机制可以在虚拟机之间高效地传递数据但需要适当的同步和互斥机制来处理并发访问。虚拟设备和驱动程序Hypervisor可以为虚拟机提供虚拟设备和驱动程序使得虚拟机可以与宿主机和其他虚拟机进行通信。通过虚拟设备接口和相关驱动程序虚拟机可以发送和接收数据包、访问存储资源和执行其他设备相关的操作。信号和事件Hypervisor可以使用信号和事件机制来实现虚拟机之间的通信。例如一个虚拟机可以向Hypervisor发送信号通知其他虚拟机发生了特定事件或状态变化。这些信号可以在虚拟机之间进行同步或触发相应的处理逻辑。宿主机通道有些Hypervisor提供了特定的宿主机通道允许虚拟机与宿主机之间进行通信。这些通道可以用于传递命令、状态信息、性能指标等。通常宿主机通道是通过特定的API或驱动程序提供的。其实就是要么共享内存中断要么寄存在某个程序上驱网络动、虚拟设备驱动要么Hypervisor加一套消息处理通道机制事件、信号、通道。2.4 OS间电源管理例如司机不开车时对整车进行关机那么这个命令如何在三个OS直接传递执行这里必须有一个次序并且有一个代理人。比如司机上帝发送了一个指令给汽车汽车里面的车控OS最先接收到指令教皇然后教皇下令给座舱OS大主教大主教继续给智驾OS主教传达命令然后各自去完成指令。教皇就是Host OS其他的都是Guest OS。Host OS和Guest OS的通信就是上面3章说的一种方法即可。例如采用中断共享内存那么两个OS都需要注册对应的中断处理函数映射好共享内存Guest OS一旦接受到中断读取共享内存中的命令后就去执行。不管是Host OS或者Guest OS执行电源命令都是通过HVC命令陷入到Hypervisor去处理。2.5 计算资源模拟一般运行AUTOSAR系统的核计算能力比较弱那么如果能采用便宜又计算能力强的核利用Hypervisor技术去模拟一个M核运行AUTOSAR就比较经济了。例如ARM A核计算能力强搞上几十个通过Hypervisor统一对外提供计算能力这样就可以模拟上百个M核的计算能力。3. 车载Hypervisor3.1 技术要求Hypervisor虽在互联网领域大放异彩但汽车领域的特殊性决定了不可能完全照搬互联网的成熟经验。Hypervisor在汽车领域适配的过程中必须正视和尊重以下和互联网领域的差别1物理硬件层面。互联网的集群服务器模式可以让其拥有灵活可扩展的高计算能力和大存储能力Hypervisor完全不用操心自己需要消耗多少计算和存储资源的问题。而在成本极其敏感的汽车领域不管是当下的域控制器还是后面的高性能中央计算单元中的主芯片其计算能力和存储能力就显得捉襟见肘。降低CPU占用、AI算力消耗和存储需求将会是贯穿整车项目开发始终的工作。Hypervisor自身的轻量化能力成为衡量其能否在汽车领域大规模应用的一个关键指标2安全冗余层面。互联网领域面对的是动态的用户任务互联网大佬期望Hypervisor可以动态分配物理硬件资源有效利用闲置资源从而实现降本增效的作用汽车领域面对的是相对固定的用户计算任务任务所需硬件资源在出厂前已由工程师设计分配好。汽车大佬们期望Hypervisor在实时性、可靠性、安全性等方面可以更加出众3适配开发层面。在汽车领域MCU/MPU/SOC类型丰富的你无法想象操作系统多的也让你数不胜数如何减少Hypervisor在适配底层不同硬件和上层不同操作系统的工作量是横亘在Hypervisor面前的另外一座高山。汽车领域和互联网领域的差别决定了Hypervisor要想在汽车领域继续攻城拔寨必须继续修炼直至拥有如下能力1安全冗余层面。Hypervisor必须具备通过资源分区技术严格隔离和分配资源的能力。当一个虚拟机中的应用程序出现故障时只可以影响分配给它的内存而不会影响其它虚拟机的内存池。当然前提是开发人员提前规划好应用的内存需求。2通用开发框架层面。汽车领域需要一种权威的Hypervisor通用框架和标准接口以减少适配底层不同硬件和上层不同操作系统时的开发工作量。目前VirtIO标准已得到汽车行业一众巨头的支持未来有希望脱颖而出实现大一统3任务调度机制。汽车领域存在大量实时任务和非实时任务而这两种系统对于任务的时间响应要求有着本质的不同。Hypervisor应该具备灵活的时间调度机制既能支持基于优先级的任务调度方式又能支持基于时间片的任务调度方式4进程间通信机制。Hypervisor在对虚拟机进行严格安全隔离的同时也需要支持不同虚拟机进程之间以受控方式进行相互通信。而最基本的进程间通信包括同步消息传递和共享内存两种方式。3.2 三域应用车控使用主要注重资源的独占例如独占核甚至其某个主要程序需要独占一个核心强调实时性智驾需要AI大量计算可能需要80%以上的计算资源分配。另外摄像头等设备的虚拟化也有需求。座舱注重响应还有外设的使用例如支持多个屏幕的显示资源动态分配安全隔离维度车控域座舱域智驾域核心需求实时性、安全性生态兼容性、交互体验大算力融合、实时性Hypervisor类型Type-1型Bao/ACRNType-1型QNX HypervisorType-1型ACRN/定制化资源管理静态分区优先级调度动态分配多屏支持资源预留异构计算典型挑战形式化验证、故障隔离多OS兼容性、调试效率跨域通信延迟、算力弹性扩展3.3 在AUTOSAR上的使用依赖硬件虚拟化扩展AUTOSAR CPClassic Platform通常运行在MCU如NXP S32K、瑞萨RH850上需Hypervisor支持ARM TrustZone或Intel VT-x等硬件虚拟化技术以实现安全关键系统如动力控制与非安全系统如诊断服务的隔离。EB tresos Hypervisor案例该Hypervisor专为实时应用设计支持在单个MCU上并行运行多个AUTOSAR协议栈实例通过硬件虚拟化扩展降低上下文切换开销确保实时任务如CAN通信在微秒级时间内完成。强实时性要求AUTOSAR CP需满足ISO 26262 ASIL-D功能安全等级Hypervisor需采用静态分区调度确保关键任务如制动控制优先占用CPU资源防止非关键任务如日志记录干扰。Mentor嵌入式Hypervisor案例该Hypervisor通过优先级抢占调度算法使AUTOSAR实时任务在10ms内完成响应同时通过内存保护机制防止缓冲区溢出攻击。静态资源分配AUTOSAR CP需严格分配CPU核心、内存带宽等资源防止任务间竞争。例如为安全关键系统预留专用CPU核心确保其不受其他任务影响。Bao Hypervisor案例Bao采用静态分区设计通过形式化验证确保资源分配的确定性满足车规级功能安全要求。强隔离性要求AUTOSAR CP需防止非安全系统如娱乐系统故障影响安全关键系统如动力控制Hypervisor需通过硬件隔离如ARM TrustZone或软件隔离如内存保护单元MPU实现。AUTOSAR与Hypervisor整合案例东软NeuSAR DS平台将AUTOSAR CP与Hypervisor融合通过静态分区隔离安全关键任务同时提供工具链支持特定平台如瑞萨R-Car H3的配置与编译。跟A核使用的差异点场景AUTOSAR环境A核Linux环境核心需求实时性、安全性生态兼容性、交互体验Hypervisor类型Type-1型EB tresos/BaoType-1型ACRN/Xen或Type-2型KVM资源管理静态分区优先级调度动态分配多屏支持安全隔离硬件隔离TrustZone形式化验证软件隔离SELinux内存加密典型案例制动控制系统隔离ISO 26262 ASIL-D多屏座舱系统理想L9双8155芯片4. 使用举例首先有了多核大芯片然后去兼容汽车里面的多个软硬件系统这个是目标。4.1 Bao-Hypervisor那么起步怎么做为了安全起见在多核芯片里面例如20个核分出来4个核绑定一个Linux其他OS不能用这4个核这样对Linux来说好像是完全运行在自己的芯片硬件上比较稳定。外设也搞成自己专用的。所以这一阶段只是多个OS都挪到一个芯片上运行OS之间不共享资源。Bao-Hypervisor开源项目就是一个简单些的虚拟机可以实现虚拟CPU和物理CPU的一对一绑定参考https://d-nb.info/1365343391/34代码bao-project/bao-hypervisor.git目录结构及其简要说明src: 包含核心的Hypervisor源代码针对Armv8架构实现了静态分区功能。 arch: 架构相关代码特别是针对Arm体系结构的实现。 drivers: 设备驱动程序用于Hypervisor与硬件交互。 include: 头文件定义了接口和数据结构。 libbaohyp: 库函数提供给Hypervisor内部使用的通用功能。 scripts: 启动脚本和构建工具链帮助编译和部署Hypervisor。 docs: 文档资料包括设计文档和技术白皮书。 examples: 示例配置和演示案例展示如何设置不同的客机操作系统。 tools: 辅助工具可能包括调试或配置辅助程序那么再进一步就可以发挥Hypervisor的优势了这就是静态到动态的转变共享可以大大的节省成本。4.2 QNX HypervisorQNX Hypervisor是一款用于实时互联嵌入式系统的实时 1 类虚拟化解决方案QNX Hypervisor充分利用了硬件虚拟化功能来执行内存CPU内核PCI配置以及虚拟机之间的中断隔离。将硬件设备分配给特定的虚拟机从而将这些设备从所有其他虚拟机中隐藏。还支持基于VirtIO的块设备控制台和网络以及其他用于设备共享的半虚拟化驱动程序。通过QNX Hypervisor可以安全地整合多个操作系统使其在同一SoC上共存使用独特的QNX OS微内核体系结构构建并将安全关键组件与非安全关键组件分开。与安全相关的组件在一个操作系统上运行而非安全相关的组件则在虚拟机上的另一个操作系统上运行。通过具有最高安全合规性和预认证水平的管理程序技术可以减少安全认证时间和成本。安全隔离利用POSIX和VirtIO等标准QNX Hypervisor提供了将安全关键组件与非安全关键组件分离和隔离的功能。使用QNX Hypervisor根据系统要求混合虚拟和主机环境。主机环境是支持虚拟机的服务域。独立的隔离客户操作系统。设备共享开发功能齐全的虚拟机管理程序环境在来宾和主机之间共享图形音频触摸屏等支持未修改的AndroidLinuxQNX和其他OS的安全共存和控制通过遵循具有自适应分区的基于优先级的虚拟CPUvCPU共享模型以最大化计算吞吐量QNX Hypervisor提供了高性能的虚拟化环境。建立可靠的系统而不会浪费资源确保共享CPU时较高优先级的来宾OS将抢占较低优先级的来宾OS满足嵌入式零停机生产系统的精度要求。QNX 技术支持客户操作系统共享 GPU 设备由此可以允许虚拟机客户操作系统渲染图形输出输出到远程独立和专用外部显示器。虚拟机间通信在多个虚拟机中运行的应用程序必须协同工作才能交付嵌入式设备的服务。QNX Hypervisor支持虚拟机之间的共享内存访问共享文件访问以及高速TCP / IP / UDP网络连接以允许在多个虚拟机中运行的应用程序进行高效通信。QNX客户机QNX Hypervisor支持QNXNeutrino®OSLinux和Android操作系统以及其他未修改的操作系统RTOS和实时执行程序。QNX Hypervisor实现为经过业界验证的基于QNX Neutrino微内核的RTOS的虚拟化扩展继承QNX操作系统的所有实时性和稳定性。通过使用QNX Hyperviosr简化系统配置和资源分配提高开发效率有效减少产品开发周期并能通过硬件集成来降低成本。4.3 ACRNACRN是linux针对IOT网络开源的type 1 hypervisor项目。ACRN 是一种灵活、轻量级的虚拟机管理程序在构建时考虑到了实时性和安全性并经过优化。 ACRN 定义了一个设备管理程序参考堆栈和一个体系结构用于在使用虚拟机管理器 (VMM) 的整合系统上运行多个安全管理的软件子系统。 它还定义了虚拟设备仿真的参考框架实现称为“ACRN 设备模型”。上图左侧所示资源由预启动的用户虚拟机 (VM) 进行分区和使用。 预启动意味着它由hypervisor直接启动甚至在服务 VM 启动之前。 预启动的 VM 独立于其他虚拟机运行并拥有专用的硬件资源例如 CPU 内核、内存和 I/O 设备。 其他虚拟机甚至可能不知道预启动的 VM 的存在。 因此它可以用作安全操作系统虚拟机。 比如平台硬件故障检测代码在这个预先启动的 VM 中运行并在发生系统严重故障时采取紧急措施。上图右侧所示剩余的硬件资源在服务虚拟机和用户虚拟机之间共享。 服务VM类似于Xen的Dom0用户VM类似于Xen的DomU。 如果没有预先启动的虚拟机服务虚拟机是 ACRN 启动的第一个虚拟机。 服务虚拟机可以通过运行原生驱动程序直接访问硬件资源并通过设备模型为用户虚拟机提供设备共享服务。 目前服务VM是基于Linux的但也可以使用其他操作系统只要移植ACRN Device Model即可。使用场景ACRN 管理程序可用于构建汽车软件定义驾舱 (SDC) 和车载体验 (IVE) 解决方案。在此场景中汽车 SDC 系统由运行在服务 VM 中的仪表盘 (IC) 系统和运行后启动用户 VM 的车载信息娱乐 (IVI) 系统组成。 此外可以修改 SDC 场景以添加更多可托管后座娱乐 (RSE) 系统图中未显示的发post-launched用户虚拟机。仪表盘 (IC) 系统用于向驾驶员显示有关车辆的操作信息例如汽车的速度、油位、行驶里程和其他驾驶信息在挡风玻璃上投射平视图像并在燃油或轮胎压力低时发出警报显示用于停车辅助的后视和环视摄像头。车载信息娱乐 (IVI) 系统的功能包括导航系统、收音机和其他娱乐系统通过语音识别连接到移动设备以进行电话、音乐和应用程序通过手势识别或触摸控制交互。后座娱乐 (RSE) 系统可以运行娱乐系统虚拟办公室;连接到前座 IVI 系统和移动设备云连接通过语音识别连接到移动设备以进行电话、音乐和应用程序通过手势识别或触摸控制交互。后记整体来说Hypervisor跟OS一样开源的众多已经不是有技术门槛的事情了。但是其靠近硬件如果使用开源自研还是需要人力的投入去修改适配代码特别是业务新加虚拟设备用于VM间通信的场景。“啥都懂一点啥都不精通干啥都能干干啥啥不是专业入门劝退堪称程序员杂家”。欢迎各位有自己公众号的留言申请转载纯干货持续更新欢迎分享给朋友、点赞、收藏、评论交流公众号“那路谈OS与SoC嵌入式软件”欢迎关注个人文章汇总https://thatway1989.github.io
Hypervisor入门-基本概念及在汽车中的应用
上篇文章汽车电子架构演进五-三域融合之“三国杀”随着EEA汽车电子电气架构的发展关于域融合的话题也比较多其中除了硬件芯片集成的发展另一方面就是Hypervisor虚拟机。目前在分散的三域中有很多OS例如汽车仪表系统与信息娱乐系统汽车仪表系统与动力系统密切相关要求具有高实时性、高可靠性和强安全性如QNX操作系统而信息娱乐系统主要为车内人机交互提供控制平台追求多样化的应用与服务如Linux和Android操作系统。所以在未来集中式架构中不同处理优先级和不同安全等级要求的应用程序将被高度集成在中央计算单元中软件复杂度比传统车载软件要超出1-2个量级对汽车安全性的要求也大大提升。虚拟化Hypervisor解决方案提供了在同一硬件平台上承载异构操作系统的灵活性同时实现了良好的高可靠性和故障控制机制, 以保证关键任务、硬实时应用程序和一般用途、不受信任的应用程序之间的安全隔离实现了车载计算单元整合与算力共享。之前有一篇文章电源管理入门-20 Hypervisor中的电源管理基本把Hypervisor讲清楚了这里我们再回顾下其基础知识然后再进行补充一下在汽车域融合中的应用。1. Hypervisor介绍1.1 Hypervisor分类虚拟机管理器又称Hypervisor 也称为虚拟机监控程序VMM,其处于SoC 硬件平台之上将实体资源如CPU、内存、存储空间、网络适配器、外设等) 转换为虚拟资源按需分配给每个虚拟机允许它们独立地访问已授权的虚拟资源。Hypervisor实现了硬件资源的整合和隔离使应用程序既能共享CPU等物理硬件也能依托不同的内核环境和驱动运行从而满足现代复杂软硬件系统多元化应用场景需求。目前通常使用两种类型的管理程序Type 1:裸机虚拟机管理程序一种在硬件上本机运行的管理程序。Type 2:托管虚拟机监控程序此类型的虚拟机监控程序必须由另一个操作系统托管并且仅负责使用主机操作系统可用的资源来虚拟化客户操作系统。|类型|优点|缺点|| — | — | — ||Type 1|不必预先加载底层操作系统直接访问底层硬件而无需其他软件(例如操作系统和设备驱动程序)速度快直接在物理硬件上运行相对较安全因为裸机虚拟机管理程序可避免操作系统通常存在的安全问题和漏洞。这可确保每个访客VM与恶意软件和活动保持逻辑隔离。|移植成本较高||Type 2|通用性强好移植|底层操作系统的存在会引入不可避免的延迟因为所有该管理程序的活动和每个VM的工作都必须通过主机操作系统。主机操作系统中的任何安全问题或漏洞都可能会危及在其上运行的所有虚拟机。因此Type2管理程序通常不用于数据中心计算并且仅用于客户端或最终用户系统其中性能和安全性较少受到关注。|我们在大SoC域融合场景下使用的就是Type 1的模式Hypervisor直接运行是硬件上向上层OS提供服务。VMM首先需要对CPU、内存、中断等资源进行管理并提供对应虚拟化功能按照I/O设备驱动的布局又可以分为Hypervisor模型和混合模型Hypervisor模型VMM设备驱动提供物理设备驱动管理并向上提供服务混合模型VMM只提供必要的CPU资源管理由Guest Server OS提供设备管理和虚拟化服务。参考Hypervisor模型QNX参考混合模型代表有XenIntel的Acrn以及国内的minos和bao-hypervisor1.2 ARM上的位置Type 1的Hypervisor向上面的OS提供服务但是OS之下是各种固件那么Hypervisor在这一堆固件中的位置在哪里这涉及到具体的代码实现。首先参考上图中ARM异常等级及安全世界和非安全世界的划分EL0非安全态的Apps安全态的Trusted AppsEL0是无特权模式所有APP应用都在EL0。EL1非安全态的Normal world OS安全态的Trusted OS EL1是一个特权模式能够执行一些特权指令用于运行各类操作系统EL2Hypervisor虚拟层EL3Secure MonitorArm trusted firmware安全固件EL3具有最高管理权限负责安全监测和Secure World和Normal World之间的切换。EL0 EL1: SVC (system call)EL1 EL2: HVC (hypervisor call)EL2 EL3: SMC (secure monitor call)在ATFARM底层固件中Hypervisor的位置如下可见Hypervisor在BL31ATF之上所以OS的SMC系统调用请求是先陷入Hypervisor如果Hypervisor处理不了再去BL31的。2. 汽车中的应用为什么汽车中迫切需求Hypervisor汽车上有三个域车身域、座舱域、智驾域。也就是说有三个OS运行在复杂的SoC上。在域融合的同时要保证关键业务的安全可靠也要考虑应用生态的可持续性兼容这就需要有资源隔离技术来支撑在同一 SOC 上切分资源可并发运行多种操作系统保障互不干扰。基于安全和资源隔离的需求需要Hypervisor。2.1 资源分配隔离Hypervisor处于 SoC 硬件平台之上将实体资源如 CPU、内存、存储空间、网络适配器、外设等 ) 转换为虚拟资源按需分配给每个虚拟机允许它们独立地访问已授权的虚拟资源。Hypervisor 实现了硬件资源的整合和隔离使应用程序既能共享 CPU 等物理硬件也能依托不同的内核环境和驱动运行从而满足汽车领域多元化应用场景需求。资源隔离技术有很多为什么是Hypervisor资源隔离技术有多种从硬件底层逐层向上包括硬件隔离、虚拟化隔离、容器隔离、进程隔离等。硬件隔离的隔离性最好单隔离域的性能、安全可靠性最好但灵活性、可配置性差不能实现硬件共享导致整个系统的资源利用率差不能充分达到软件定义汽车的目标。容器隔离、进程隔离可以更轻量级地实现业务隔离但还是在同一个操作系统内存在着资源干扰、相互安全攻击的隐患并且无法支持异构操作系统业务域融合影响传统业务继承不利于生态发展。在众多的资源隔离技术中虚拟化是安全可靠、弹性灵活的优选方案是软件定义汽车的重要支撑技术。Hypervisor的特点隔离VM之间资源隔离资源共享VM间资源更新负载均衡根据VM对资源使用情况动态调配供给高可用VM与硬件解绑硬件出问题时VM可以迅速迁移到其他硬件弹性伸缩根据业务情况开关不同的VM这里汽车上主要使用隔离和资源共享功能。在汽车领域Hypervisior 主要完成以下任务CPU虚拟化为虚拟机提供 VCPU 资源和运行环境内存虚拟化负责为其自身和虚拟机分配和管理硬件内存资源中断虚拟化发生中断和异常时按需将中断和异常路由到虚拟机进行处理虚拟机设备模拟根据需求创建虚拟机可以访问的虚拟硬件组件硬件支持 BSP提供 Hypervisor 在 SoC上运行的板级支持包如串口驱动虚拟机资源配置对虚拟机的 CPU内存IO 外设等资源进行配置和管理虚拟机通信为虚拟机提供 IPC共享内存等通信机制。虚拟机调度为虚拟机提供优先级和时间片等调度算法虚拟机生命周期管理创建启动和停止虚拟机虚拟机调测服务提供控制台日志等调试功能2.1.1 CPU虚拟化VM管理VM都是运行在CPU上的所以Hypervisor对vCPU的管理就可以管理VM的生命周期了。一个VM在Hypervisor中类似一个进程有自己的页表空间和IPA空间其可以有别的VM创建也可系统启动静态配置拉起。vCPU的管理首先就是虚拟CPU和物理CPU的绑定策略。对于车控这种安全要求高的系统在Hypervisor上尽量分配静态的资源例如进行绑核处理这样就有了专用核硬件保证资源专用充足从而实现实时性需求。Hypervisor的陷入管理: VM主动HVC、SMC trap进入Hypervisor或者异常缺页、特权寄存器访问的情况陷入vCPU上下文主要就是CPU的寄存器例如正常我们在执行WFI指令时会使CPU进入一个低功耗的状态但是对于HOST OS来说如果让CPU真正进入低功耗状态显然会影响其他VM的运行。如果我们配置了HCR_EL2.TWI1时那么Guest OS在执行WFI时就会触发EL2的异常然后陷入Hypervisor那么此时Hypervisor就可以将对应VCPU所处的线程调出出去将CPU让给其他的VCPU线程使用。2.1.2 内存虚拟化内存虚拟化的目的是给虚拟客户机操作系统提供一个从0开始的连续的地址空间同时在多个客户机之间实现隔离与调度。arm主要通过Stage 2转换来提供对内存虚拟化的支持其允许Hypervisor控制虚拟机的内存视图而在这之前则是使用及其复杂的影子页表技术来实现。Stage 2转换可以控制虚拟机是否可以访问特定的某一块物理内存以及该内存块出现在虚拟机内存空间的位置。这种能力对于虚拟机的隔离和沙箱功能来说至关重要。这使得虚拟机只能看到分配给它自己的物理内存。为了支持Stage 2 转换 需要增加一个页表我们称之为Stage 2页表。操作系统控制的页表转换称之为stage 1转换负责将虚拟机视角的虚拟地址转换为虚拟机视角的物理地址。而stage 2页表由Hypervisor控制负责将虚拟机视角的物理地址转换为真实的物理地址。虚拟机视角的物理地址在Armv8中有特定的词描述叫中间物理地址(intermediate Physical Address, IPA)。stage 2转换表的格式和stage 1的类似但也有些属性的处理不太一样例如,判断内存类型 是normal 还是 device的信息被直接编码进了表里而不是通过查询MAIR_ELx寄存器。2.1.3 中断虚拟化中断从设备发送到CPU需要经过中断控制器现代x86架构采用的中断控制器被称为APIC**(Advanced Programmable Interrupt Controller)。APIC是伴随多核处理器产生的所有的核共用一个**I/O APIC用于统一接收来自外部I/O设备的中断而后根据软件的设定格式化出一条包含该中断所有信息的Interrupt Message发送给对应的CPU。每个核有一个Local APIC用于接收来自I/O APIC的Interrupt Message内部的时钟和温控中断以及来自其他核的中断也就是IPI(Inter-Processor Interrupt)。在虚拟化环境中VMM需要为guest VM展现一个与物理中断架构类似的虚拟中断架构。每个虚拟CPU都对应一个虚拟的Local APIC多个虚拟CPU共享一个虚拟的I/O APIC。和虚拟CPU一样虚拟的Local APIC和虚拟的I/O APIC都是VMM维护的软件实体以下统称虚拟中断控制器。中断虚拟化的主要任务就是实现下图描述的虚拟中断架构包括虚拟中断控制器的创建中断采集和中断注入。2.1.4 IO虚拟化I/O设备作为一种外部设备其虚拟化的实现相较于前面的CPU虚拟化及内存虚拟化有些不同其目前主要有以下四种虚拟化方案。1、 设备模拟在虚拟机监控器中模拟具体的I/O设备的特性例如qemu。在KVM和qemu的组合中通过Hypervisor捕获Guest OS的I/O请求交给用户空间的qemu进行模拟然后将结果再通过Hypervisor传递给Guest OS。这种方式能够提供非常好的兼容性但是性能太差同时模拟设备的功能特性支持不够多。2、 前后端驱动接口在Hypervisor和Guest OS之间定义一种权限的适用于虚拟机的交互接口比如virtio技术。这个方案相较于设备模拟在性能上有所提高但是兼容性较差而且在高I/O负载场景后端驱动的CPU占用较高。3、 设备直接分配将一个物理设备直接分配给Guest OS使用。此方式的性能显而易见要比上面两种好很多但是需要硬件设备支持且无法共享和动态迁移。4、 设备共享分配此方式是设备直接分配的一个扩展其主要就是让一个物理设备可以支持多个虚拟机功能接口将不同的接口地址独立分配给不同的Guest OS使用。如SR-IOV协议。2.2 OS间通信Hypervisor中有很多技术例如CPU 虚拟化和节能降耗技术、IO 设备虚拟化、实时性技术、安全和可靠性技术等大家可以自己查资料去学习特别是参考国内的minosbao-hypervisor开源软件去学习修改使用大家懂的。这里主要介绍下多OS的通信技术后面在介绍多OS电源管理时会用到。Hypervisor虚拟化管理程序是一种软件或硬件层面的虚拟化技术用于在物理计算机上运行多个虚拟操作系统OS。Hypervisor需要提供一种有效的机制以便不同虚拟机VM之间以及虚拟机与宿主机host之间进行通信。以下是几种常见的Hypervisor的OS间通信机制虚拟网络Hypervisor可以创建虚拟网络为虚拟机提供网络连接和通信功能。虚拟网络允许虚拟机之间进行网络通信就像它们连接在同一物理网络上一样。这种通信机制基于网络协议和虚拟网络设备的实现。共享内存Hypervisor可以在物理内存中创建共享区域允许不同的虚拟机共享内存数据。通过在共享内存区域中读取和写入数据虚拟机可以进行相互通信。这种通信机制可以在虚拟机之间高效地传递数据但需要适当的同步和互斥机制来处理并发访问。虚拟设备和驱动程序Hypervisor可以为虚拟机提供虚拟设备和驱动程序使得虚拟机可以与宿主机和其他虚拟机进行通信。通过虚拟设备接口和相关驱动程序虚拟机可以发送和接收数据包、访问存储资源和执行其他设备相关的操作。信号和事件Hypervisor可以使用信号和事件机制来实现虚拟机之间的通信。例如一个虚拟机可以向Hypervisor发送信号通知其他虚拟机发生了特定事件或状态变化。这些信号可以在虚拟机之间进行同步或触发相应的处理逻辑。宿主机通道有些Hypervisor提供了特定的宿主机通道允许虚拟机与宿主机之间进行通信。这些通道可以用于传递命令、状态信息、性能指标等。通常宿主机通道是通过特定的API或驱动程序提供的。其实就是要么共享内存中断要么寄存在某个程序上驱网络动、虚拟设备驱动要么Hypervisor加一套消息处理通道机制事件、信号、通道。2.4 OS间电源管理例如司机不开车时对整车进行关机那么这个命令如何在三个OS直接传递执行这里必须有一个次序并且有一个代理人。比如司机上帝发送了一个指令给汽车汽车里面的车控OS最先接收到指令教皇然后教皇下令给座舱OS大主教大主教继续给智驾OS主教传达命令然后各自去完成指令。教皇就是Host OS其他的都是Guest OS。Host OS和Guest OS的通信就是上面3章说的一种方法即可。例如采用中断共享内存那么两个OS都需要注册对应的中断处理函数映射好共享内存Guest OS一旦接受到中断读取共享内存中的命令后就去执行。不管是Host OS或者Guest OS执行电源命令都是通过HVC命令陷入到Hypervisor去处理。2.5 计算资源模拟一般运行AUTOSAR系统的核计算能力比较弱那么如果能采用便宜又计算能力强的核利用Hypervisor技术去模拟一个M核运行AUTOSAR就比较经济了。例如ARM A核计算能力强搞上几十个通过Hypervisor统一对外提供计算能力这样就可以模拟上百个M核的计算能力。3. 车载Hypervisor3.1 技术要求Hypervisor虽在互联网领域大放异彩但汽车领域的特殊性决定了不可能完全照搬互联网的成熟经验。Hypervisor在汽车领域适配的过程中必须正视和尊重以下和互联网领域的差别1物理硬件层面。互联网的集群服务器模式可以让其拥有灵活可扩展的高计算能力和大存储能力Hypervisor完全不用操心自己需要消耗多少计算和存储资源的问题。而在成本极其敏感的汽车领域不管是当下的域控制器还是后面的高性能中央计算单元中的主芯片其计算能力和存储能力就显得捉襟见肘。降低CPU占用、AI算力消耗和存储需求将会是贯穿整车项目开发始终的工作。Hypervisor自身的轻量化能力成为衡量其能否在汽车领域大规模应用的一个关键指标2安全冗余层面。互联网领域面对的是动态的用户任务互联网大佬期望Hypervisor可以动态分配物理硬件资源有效利用闲置资源从而实现降本增效的作用汽车领域面对的是相对固定的用户计算任务任务所需硬件资源在出厂前已由工程师设计分配好。汽车大佬们期望Hypervisor在实时性、可靠性、安全性等方面可以更加出众3适配开发层面。在汽车领域MCU/MPU/SOC类型丰富的你无法想象操作系统多的也让你数不胜数如何减少Hypervisor在适配底层不同硬件和上层不同操作系统的工作量是横亘在Hypervisor面前的另外一座高山。汽车领域和互联网领域的差别决定了Hypervisor要想在汽车领域继续攻城拔寨必须继续修炼直至拥有如下能力1安全冗余层面。Hypervisor必须具备通过资源分区技术严格隔离和分配资源的能力。当一个虚拟机中的应用程序出现故障时只可以影响分配给它的内存而不会影响其它虚拟机的内存池。当然前提是开发人员提前规划好应用的内存需求。2通用开发框架层面。汽车领域需要一种权威的Hypervisor通用框架和标准接口以减少适配底层不同硬件和上层不同操作系统时的开发工作量。目前VirtIO标准已得到汽车行业一众巨头的支持未来有希望脱颖而出实现大一统3任务调度机制。汽车领域存在大量实时任务和非实时任务而这两种系统对于任务的时间响应要求有着本质的不同。Hypervisor应该具备灵活的时间调度机制既能支持基于优先级的任务调度方式又能支持基于时间片的任务调度方式4进程间通信机制。Hypervisor在对虚拟机进行严格安全隔离的同时也需要支持不同虚拟机进程之间以受控方式进行相互通信。而最基本的进程间通信包括同步消息传递和共享内存两种方式。3.2 三域应用车控使用主要注重资源的独占例如独占核甚至其某个主要程序需要独占一个核心强调实时性智驾需要AI大量计算可能需要80%以上的计算资源分配。另外摄像头等设备的虚拟化也有需求。座舱注重响应还有外设的使用例如支持多个屏幕的显示资源动态分配安全隔离维度车控域座舱域智驾域核心需求实时性、安全性生态兼容性、交互体验大算力融合、实时性Hypervisor类型Type-1型Bao/ACRNType-1型QNX HypervisorType-1型ACRN/定制化资源管理静态分区优先级调度动态分配多屏支持资源预留异构计算典型挑战形式化验证、故障隔离多OS兼容性、调试效率跨域通信延迟、算力弹性扩展3.3 在AUTOSAR上的使用依赖硬件虚拟化扩展AUTOSAR CPClassic Platform通常运行在MCU如NXP S32K、瑞萨RH850上需Hypervisor支持ARM TrustZone或Intel VT-x等硬件虚拟化技术以实现安全关键系统如动力控制与非安全系统如诊断服务的隔离。EB tresos Hypervisor案例该Hypervisor专为实时应用设计支持在单个MCU上并行运行多个AUTOSAR协议栈实例通过硬件虚拟化扩展降低上下文切换开销确保实时任务如CAN通信在微秒级时间内完成。强实时性要求AUTOSAR CP需满足ISO 26262 ASIL-D功能安全等级Hypervisor需采用静态分区调度确保关键任务如制动控制优先占用CPU资源防止非关键任务如日志记录干扰。Mentor嵌入式Hypervisor案例该Hypervisor通过优先级抢占调度算法使AUTOSAR实时任务在10ms内完成响应同时通过内存保护机制防止缓冲区溢出攻击。静态资源分配AUTOSAR CP需严格分配CPU核心、内存带宽等资源防止任务间竞争。例如为安全关键系统预留专用CPU核心确保其不受其他任务影响。Bao Hypervisor案例Bao采用静态分区设计通过形式化验证确保资源分配的确定性满足车规级功能安全要求。强隔离性要求AUTOSAR CP需防止非安全系统如娱乐系统故障影响安全关键系统如动力控制Hypervisor需通过硬件隔离如ARM TrustZone或软件隔离如内存保护单元MPU实现。AUTOSAR与Hypervisor整合案例东软NeuSAR DS平台将AUTOSAR CP与Hypervisor融合通过静态分区隔离安全关键任务同时提供工具链支持特定平台如瑞萨R-Car H3的配置与编译。跟A核使用的差异点场景AUTOSAR环境A核Linux环境核心需求实时性、安全性生态兼容性、交互体验Hypervisor类型Type-1型EB tresos/BaoType-1型ACRN/Xen或Type-2型KVM资源管理静态分区优先级调度动态分配多屏支持安全隔离硬件隔离TrustZone形式化验证软件隔离SELinux内存加密典型案例制动控制系统隔离ISO 26262 ASIL-D多屏座舱系统理想L9双8155芯片4. 使用举例首先有了多核大芯片然后去兼容汽车里面的多个软硬件系统这个是目标。4.1 Bao-Hypervisor那么起步怎么做为了安全起见在多核芯片里面例如20个核分出来4个核绑定一个Linux其他OS不能用这4个核这样对Linux来说好像是完全运行在自己的芯片硬件上比较稳定。外设也搞成自己专用的。所以这一阶段只是多个OS都挪到一个芯片上运行OS之间不共享资源。Bao-Hypervisor开源项目就是一个简单些的虚拟机可以实现虚拟CPU和物理CPU的一对一绑定参考https://d-nb.info/1365343391/34代码bao-project/bao-hypervisor.git目录结构及其简要说明src: 包含核心的Hypervisor源代码针对Armv8架构实现了静态分区功能。 arch: 架构相关代码特别是针对Arm体系结构的实现。 drivers: 设备驱动程序用于Hypervisor与硬件交互。 include: 头文件定义了接口和数据结构。 libbaohyp: 库函数提供给Hypervisor内部使用的通用功能。 scripts: 启动脚本和构建工具链帮助编译和部署Hypervisor。 docs: 文档资料包括设计文档和技术白皮书。 examples: 示例配置和演示案例展示如何设置不同的客机操作系统。 tools: 辅助工具可能包括调试或配置辅助程序那么再进一步就可以发挥Hypervisor的优势了这就是静态到动态的转变共享可以大大的节省成本。4.2 QNX HypervisorQNX Hypervisor是一款用于实时互联嵌入式系统的实时 1 类虚拟化解决方案QNX Hypervisor充分利用了硬件虚拟化功能来执行内存CPU内核PCI配置以及虚拟机之间的中断隔离。将硬件设备分配给特定的虚拟机从而将这些设备从所有其他虚拟机中隐藏。还支持基于VirtIO的块设备控制台和网络以及其他用于设备共享的半虚拟化驱动程序。通过QNX Hypervisor可以安全地整合多个操作系统使其在同一SoC上共存使用独特的QNX OS微内核体系结构构建并将安全关键组件与非安全关键组件分开。与安全相关的组件在一个操作系统上运行而非安全相关的组件则在虚拟机上的另一个操作系统上运行。通过具有最高安全合规性和预认证水平的管理程序技术可以减少安全认证时间和成本。安全隔离利用POSIX和VirtIO等标准QNX Hypervisor提供了将安全关键组件与非安全关键组件分离和隔离的功能。使用QNX Hypervisor根据系统要求混合虚拟和主机环境。主机环境是支持虚拟机的服务域。独立的隔离客户操作系统。设备共享开发功能齐全的虚拟机管理程序环境在来宾和主机之间共享图形音频触摸屏等支持未修改的AndroidLinuxQNX和其他OS的安全共存和控制通过遵循具有自适应分区的基于优先级的虚拟CPUvCPU共享模型以最大化计算吞吐量QNX Hypervisor提供了高性能的虚拟化环境。建立可靠的系统而不会浪费资源确保共享CPU时较高优先级的来宾OS将抢占较低优先级的来宾OS满足嵌入式零停机生产系统的精度要求。QNX 技术支持客户操作系统共享 GPU 设备由此可以允许虚拟机客户操作系统渲染图形输出输出到远程独立和专用外部显示器。虚拟机间通信在多个虚拟机中运行的应用程序必须协同工作才能交付嵌入式设备的服务。QNX Hypervisor支持虚拟机之间的共享内存访问共享文件访问以及高速TCP / IP / UDP网络连接以允许在多个虚拟机中运行的应用程序进行高效通信。QNX客户机QNX Hypervisor支持QNXNeutrino®OSLinux和Android操作系统以及其他未修改的操作系统RTOS和实时执行程序。QNX Hypervisor实现为经过业界验证的基于QNX Neutrino微内核的RTOS的虚拟化扩展继承QNX操作系统的所有实时性和稳定性。通过使用QNX Hyperviosr简化系统配置和资源分配提高开发效率有效减少产品开发周期并能通过硬件集成来降低成本。4.3 ACRNACRN是linux针对IOT网络开源的type 1 hypervisor项目。ACRN 是一种灵活、轻量级的虚拟机管理程序在构建时考虑到了实时性和安全性并经过优化。 ACRN 定义了一个设备管理程序参考堆栈和一个体系结构用于在使用虚拟机管理器 (VMM) 的整合系统上运行多个安全管理的软件子系统。 它还定义了虚拟设备仿真的参考框架实现称为“ACRN 设备模型”。上图左侧所示资源由预启动的用户虚拟机 (VM) 进行分区和使用。 预启动意味着它由hypervisor直接启动甚至在服务 VM 启动之前。 预启动的 VM 独立于其他虚拟机运行并拥有专用的硬件资源例如 CPU 内核、内存和 I/O 设备。 其他虚拟机甚至可能不知道预启动的 VM 的存在。 因此它可以用作安全操作系统虚拟机。 比如平台硬件故障检测代码在这个预先启动的 VM 中运行并在发生系统严重故障时采取紧急措施。上图右侧所示剩余的硬件资源在服务虚拟机和用户虚拟机之间共享。 服务VM类似于Xen的Dom0用户VM类似于Xen的DomU。 如果没有预先启动的虚拟机服务虚拟机是 ACRN 启动的第一个虚拟机。 服务虚拟机可以通过运行原生驱动程序直接访问硬件资源并通过设备模型为用户虚拟机提供设备共享服务。 目前服务VM是基于Linux的但也可以使用其他操作系统只要移植ACRN Device Model即可。使用场景ACRN 管理程序可用于构建汽车软件定义驾舱 (SDC) 和车载体验 (IVE) 解决方案。在此场景中汽车 SDC 系统由运行在服务 VM 中的仪表盘 (IC) 系统和运行后启动用户 VM 的车载信息娱乐 (IVI) 系统组成。 此外可以修改 SDC 场景以添加更多可托管后座娱乐 (RSE) 系统图中未显示的发post-launched用户虚拟机。仪表盘 (IC) 系统用于向驾驶员显示有关车辆的操作信息例如汽车的速度、油位、行驶里程和其他驾驶信息在挡风玻璃上投射平视图像并在燃油或轮胎压力低时发出警报显示用于停车辅助的后视和环视摄像头。车载信息娱乐 (IVI) 系统的功能包括导航系统、收音机和其他娱乐系统通过语音识别连接到移动设备以进行电话、音乐和应用程序通过手势识别或触摸控制交互。后座娱乐 (RSE) 系统可以运行娱乐系统虚拟办公室;连接到前座 IVI 系统和移动设备云连接通过语音识别连接到移动设备以进行电话、音乐和应用程序通过手势识别或触摸控制交互。后记整体来说Hypervisor跟OS一样开源的众多已经不是有技术门槛的事情了。但是其靠近硬件如果使用开源自研还是需要人力的投入去修改适配代码特别是业务新加虚拟设备用于VM间通信的场景。“啥都懂一点啥都不精通干啥都能干干啥啥不是专业入门劝退堪称程序员杂家”。欢迎各位有自己公众号的留言申请转载纯干货持续更新欢迎分享给朋友、点赞、收藏、评论交流公众号“那路谈OS与SoC嵌入式软件”欢迎关注个人文章汇总https://thatway1989.github.io
