智能座舱的影分身术：Hypervisor（一）
第一次接触Hypervisor大约是2003年左右，在Linux上通过VMware运行Windows；2007年在联想花了一个月研究Xen/KVM在服务端的应用，再往后几年放弃了Linux桌面。
离开了研发团队就再也没有了同时运行多个系统的需求，虚拟化技术被抛到脑后，看到Hypervisor在终端设备上的应用，我第一反应是虚拟化还可以这么玩！
为了便于大家理解这个概念，我再举个不准确的例子。
一个计算机假设有10亿个计算单元，每次执行任务时只能只有1亿个被用到，这时我们可以假设这个1计算机是10个计算机。这10个计算机可以同时做不同的事，比如一台运行财务用、一台运行开发用，但两用户互不影响。这种利用空闲资源的各种办法就叫虚拟化（Hypervisor）。
用于互联网用户而言，现在我们每时每刻都在使用基于Hypervisor的互联网云服务。云服务使用虚拟化技术的核心目的是可以动态分配资源，可以有效利用空闲资源。相当于自行车的分时租赁，每个人都交了押金，但自行车依然闲置，上下班的时候根据使用情况再调度。先简单的理解为有隔离计算能力的分时复用吧。
与云平台商业化运作的不同，车辆中虚拟化产品面对的不是动态的用户，而是各种相对固定的计算任务。算力分配在产品出厂前就已经固定，算力即不会过度闲置，也不会过度紧张，也不会动态调配，更不存在利用闲置资源进行商业变现的机会。
在汽车电子电气系统中，不同的功能单元需要不同的服务、有不同的优先级、有不同的计算安全冗余而存在。特别是需要将各种计算单元进行整合、算力共享，最终通过Hypervisor来完成降低成本。相当于以前我买五六个大件ECU，现在只需要一个，省去了大量的线束、接插件、多次生产、多次研发、多次测试的成本，减轻了车身整体重量。
未来域乐域控制器、自动驾驶域控制器、中央计算机里面都可能会使用Hypervisor技术。汽车行业对于有逼格的东西一向抱有着警惕的眼神的，Hypervisor这个很少会被翻译成中文的名称，背后就隐藏着满满的逼格，比Superman还要高一个档次。
幸好汽车行业对能省钱的东西还是喜欢的紧（考虑到自己有很长一段时间没有上手具体技术，我尽量对与技术相关的内容作价值分析，但实在看不懂相关技术，请直接跳到最后点打赏或在看）。
一、Hypervisor的主要概念
虚拟机（Hypervisor/Virtual Machine）是在同一硬件机器上，允许运行多个相互隔离的不同系统的软件技术。
虚拟化对隐藏了真实的计算机硬件，可以自已模拟成为另一种计算平台（为了更直观，大家看一下在Mac OS上运行Windows，来自parallels官网）。
1. 虚拟化的分类
- 应用程序的虚拟化：比如JAVA VM，其本质是对二进制的转换；
- 操作系统的虚拟化：比如容器/Docker技术，其本质利用对特定进程可用的算力、存储、IO资源的管理，几乎没有额外系统开销，在云服务中使用较多；
- 硬件虚拟化：比如Xen，KVM，对算力及IO的影响小，额外开销成本少。KVM是目前云计算虚拟化的主力。
虚拟化的TYPE-1与TYPE-2
- TYPE1类型的虚拟机，直接运行的硬件基础上，比如XEN。
- TYPE2类型的虚拟机，是在完整的OS上进行上进行，比如KVM。
对于最新的Hypervisor技术。无论TYPE1类型还是TYPE2类型，都可以采用硬件辅助加速功能。在汽车领域，由于算力限制、实时性要求高，多数据情况会使用硬件虚拟化技术，即TYPE1。
2. 硬件虚拟化的思路与方案
- 全虚拟化（Full-Virtualized）：依赖硬件虚拟化技术，不需要修改被虚拟系统的内核。
- 半虚拟化（Para-Virtualized)：不依赖硬件虚拟化技术，需要修改被虚拟系统的内核。
- 透传（Pass Through）:直接使用物理设备，不经过虚拟监管程序。
PV和FV都是用来描述设备被虚拟/模拟的程度，PT是直接使用物理设备，未进行虚拟化。
为什么我们使用虚拟化支持？是因为大多数的设备不支持并发性的访问。
为了并发访问设备，全虚拟化的设备将被完全仿真（所有功能），所有操作系统都不能直接访问该物理设备，所有的操作都要通过虚化监管程序协助执行，效率明显较低。
PV通过抽象理想的物理设备，采用分离设备驱动模型的方式，该模型将设备驱动分为前端驱动，后端驱动，其中前端驱动运行在guest os中，而后端驱动运行在hypervisor中，前端通过共享内存的方式交换数据，来提高效率。
通常半虚拟化性能通常高于全虚拟化，其性能非常接近设备的物理性能。常用用于PV的框架有VirtIO，来标准化半虚拟设备。
考虑到传统虚拟化技术中共享物理平台的I/O效率低下，在有足够I/O硬件可用的情况下，通过将I/O物理设备直接分配给虚拟机，虚拟机监视器不再干涉其访问独占的I/O物理设备，我们将这种方式称之为Pass Through(PT)。
PT模式，可以利用使用最新的驱动，充分发挥新硬件的功能；PV、FV面向新设备时，除了额外开销，都存在驱动更新问题。
同时如果硬件本身支持并发访问的话，XEN可借助件硬辅助虚拟化进一步减少虚拟化负责，增强虚拟化性能。
3. 支持硬件虚拟化的CPU
硬件虚拟化技术依赖于CPU与GPU等硬件设备的支持。X86架构世界的虚拟化在Intel与AMD的配合下高度一下，选择多样。
但是根据《智能座舱选择怎么样的SOC算力？》我们知道：汽车领域SOC都是ARM架构，ARM对虚拟化支持如何？
在2011年开始ARM v7-A和ARM v8-A体系结构包括可选的虚拟化扩展。
4. 汽车界虚拟化的软件
针对ARM架构，Xen是一款即支持半虚拟化，又支持全虚拟化的虚拟化软件。
可以使用ARM 硬件虚拟化扩展，支持全虚拟化方式运行，操作系统可以使用真实的设备驱动与真实的虚拟硬件直接通信，尽可能减少使用Hypervisor接口调用中仿真操作带来的开销。
除了Xen之外，还有Opensynergy、ACRN Hypervisor、Global Hypervisor、Mentor Hypervisor、QNXHypervisor、Redbend Hyeprvisor。
但目前真正有量产车型的虚拟机好象只有QNX的Hypervisor，它是目前市场上唯一被认可功能安全等级达到ASIL D级。
5. 支持GPU的虚拟化
进行虚拟化为是了串行硬件设备的复用，并行处理。与CPU的串行模型完全不同，GPU是并行编程模型。为了使用GPU的能力，我们通常使用OPEN GL、OpenCL或者GPU自身支持API来进行图形应用的开发。
GPU虚拟化方案常有以下三种模式（类似于CPU）：
PowerVR的GPU虚拟化是完整的硬件虚拟化解决方案，其中每个Guest OS都有完整的驱动程序堆栈，并可以直接向GPU提交任务硬件。该解决方案不需要用于任务提交的管理程序干预，导致最大的利用率可用的GPU资源。 PowerVR GPU最多可以支持八个虚拟机，每个操作系统可以是独立并行运行。
（Mail和Adreno的虚拟化资料我没有怎么查，不了解情况。）
二、Hypervisor靠谱吗
听到虚拟机大家可能首先想到的是被人多有诟病的JAVA虚拟机，因为执行过程中存在二进制解释过程，速度慢是其带自带属性。
车载硬件算力受限，大家也没有见过哪个手机运行过虚拟机，Hypervisor速度是不是会对计算机的性能带来很大的影响？对于新技术应该认真思考是不是靠谱，即不自大也不盲从。
车载硬件算力受限，类似大家也没有见过手机运行过虚拟机，Hypervisor速度是不是会对计算机的性能带来很大的影响？
答：不会的。
汽车产品的虚拟化一般指的是硬件虚化化技术，开销较小，通过CPU负载不超过2%，DDR小于20MB，EMMC小于50MB。大数的Hypervisor技术代码量在3万行以内，Xen的代量较大在30万量级。
既然在云服务中虚拟化技术已经被广泛的使用，那是不是说在终端产品的中使用很成熟？
答：不是的。
首先，云服务和终端产品采用Hypervisor技术的需求与目的完全不同；其次，ARM的指令集、异构运算、能耗管理不同；再次汽车功能安全要求标准不同；最后虚拟化技术在汽车领域还没有进行过大规模的量产应用。
虚拟化技术可以省多少成本？
答：理论上来讲可以降本。
从产品设计的角度来说，能降多少成本的关键在于能将多少个分布式ECU整合到域控制器中。需要进行综合衡量。
但是由于目前主要主要使用的是QNX Hypervisor + QNX仪表+ Kanzi的组合，从入门费、席位费、服务费、授权费到其他开发成本，以及有效的技术支持，从短期来看单台成本降低可能没有想的那么大，但综合来看还是值得的。
三、Hypervisor在智能座舱中的应用
Hypervisor的复杂性与影响因子很多，为什么还要在智能座舱中使用Hypervisor技术。
因为降本需求，在单个SOC上运行多个不同安全级别的操作系统最便宜（当然不是因为车内屏幕数量的增加）。
在智能座舱的想象中，假定我们运行四个系统，仪表是安全ASIL B，信息娱乐系统是ASIL QM，L0-L2级的ADAS属于ASILB或C、以及HUD系统。
这意味着我们可能需要运行三个或者四个不同的系统（仪表和HUD可能会共用一个系统，该系统支持分屏幕输出）。
作者：updatedb；公众号：强哥的面包屑 / MyCrumbs。
本文作者 @updatedb
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
