智能座舱的影分身术:Hypervisor(一)
本文主要分析了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 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
- 目前还没评论,等你发挥!