52

修志龙_ZenonXiu · 2023年04月25日 · 上海市浦东新区

Armv8-R Cortex-R52+软件集成最佳实践

本文翻译自 Best Practices for Armv8-R Cortex-R52+ Software Consolidation https://armkeil.blob.core.windows.net/developer/Files/pdf/white-paper/best-practices-for-armv8-r-cortex-r52-st2-whitepaper.pdf
原作者:

  • Paul Austin, Principal Software Engineer, ETAS
  • Dr Andrew Coombes, Senior Product Manager, ETAS
  • Paul Hughes, Lead System Architect and Distinguished Engineer ATG, Arm
  • James Scobie, Director Automotive Product Management, Arm
  • Bernhard Rill, Director Automotive Partnerships EMEA, Arm

目录

  • 介绍
  • 软件集成机制
  • 软件集成建议
  • 未来微控制器建议
  • 总结/结论

介绍

车辆电气/电子(E/E)架构正在向计算资源的集中化发展。这最初发生在域控制器(domain controllers)中,然后转向分区(Zonal)和集中化方法。
随着多个实时功能被整合到区控制器(Zonal controller)中,对处理器性能需求增加,操作系统和软件的复杂性也增加。该行业越来越倾向于采用基于Armv8-R的解决方案,如Cortex-R52和Cortex-R52+ CPU(在本文中总结为Cortex-R52+)来实现这种软件集成愿景。一些汽车芯片制造商已经将这些处理器纳入其高性能微控制器的区控制平台和安全岛设计中。与此同时,汽车软件提供商已经提供了与Armv8-R集成的解决方案。这种行业趋势的最新概述总结在本篇Arm Blueprint文章中。

新硬件和软件系统必须同时满足设备上运行的每个工作负载的要求,包括:

  • 满足工作负载的软件依赖关系,包括库、操作系统调用(包括输入/输出访问)和应用程序二进制接口(ABI)。可能需要特定版本。当单个操作系统无法同时满足所有依赖关系时,系统软件可能包括多个操作系统。
  • 性能,包括实时工作负载所需的确定性,可能具有不同的硬实时响应时间要求,从几微秒到更长时间不等。未能满足硬实时要求会导致工作负载操作不正确。一些工作负载可能具有更严格的实时要求,未能满足这些要求会导致性能下降。其他工作负载没有特定的实时要求,因此这些软件构件是以最尽力执行的。
  • 对于功能安全工作负载,满足工作负载对正确执行环境的假设以及提供任何假定的外部安全机制是基本的要求。必须给汽车安全完整性等级(ASIL)的执行环境和安全机制分配工作负载同样或是更高的优先级。
  • 对于安全性影响较小的工作负载,非常希望工作负载的ASIL不会因为设备上存在其他更高ASIL的工作负载而增加。
  • 通过确保敏感数据不可被其他工作负载访问,满足安全要求,如机密性、完整性、隐私和真实性。
  • 能够更新单个工作负载,包括通过空中固件更新(FOTA)。这还涵盖了一系列其他主题,如工作负载的身份验证、安全引导和系统级更新。针对虚拟化程序的FOTA是一个大话题,不能在本篇白皮书中涵盖。
  • 对于现有(遗存))应用程序的工作负载,一个理想的选择是进行最小限度的适应就能集成工作负载。当集成原来为独立系统硬件设计的工作负载时,软件必须防止任何行为产生的副作用影响系统中的其他应用程序。
  • 对于与监管应用程序有关的工作负载,可能需要获得认证(例如,在On-Board Diagnostics(OBD)相关应用程序的情况下)。为了避免每次另一个工作负载发生更改都需要重新认证,有必要证明其他工作负载不会干扰经认证的工作负载。

通过托管多个工作负载,系统硬件和软件必须在工作负载之间提供适当的隔离,以确保一个工作负载不会导致另一个工作负载无法满足其要求。当需要多个操作系统时,每个操作系统之间也存在类似的隔离要求。

对于功能安全性,这种隔离被称为避免相互干扰(freedom-from-interference,FFI),需要机制确保与一个工作负载相关的故障不会导致执行环境和提供给另一个工作负载的系统安全机制失败。

提供这种工作负载之间的隔离等级的系统还具有一个优点,即允许每个工作负载在与其他工作负载隔离的情况下开发(和调试)。如果工作负载来自不同的供应商,这尤其重要。

系统硬件和软件提供以下隔离机制,用于满足这些要求:

  • 逻辑隔离。使用特权模型和内存保护机制,隔离属于不同工作负载的状态。
  • 时间隔离。调度私有和共享资源,分区和监视共享资源,并管理看门狗定时器以检测时间违规。

Cortex-R概述

Arm拥有一系列CPU处理器,旨在解决从最小、最低功率微控制器到超高性能服务器级计算的各种计算需求。Cortex-R处理器用于实时处理需求的应用程序,并适用于各种不同场景,尤其是在汽车应用程序中,系统必须在短且确定的时间范围内响应,以成功满足系统时间限定要求。在许多情况下,这些应用程序还包括功能安全(和安全性)要求,增加了系统集成商和开发人员面临的挑战。Cortex-R处理器,如Cortex-R52+,可用作独立微控制器(MCU)或作为SoC(片上系统)设计中的CPU核,如作为安全岛。
第一代Cortex-R处理器,如Cortex-R5,是基于Armv7-R架构构建的。然而,随着时间 的变化,架构已经发展,Arm的Cortex-R52和Cortex-R52+处理器是基于Armv8-R架构的CPU实现,帮助解决汽车实时软件越来越复杂以及从分散专用控制器向功能集中和整合的过渡所带来的挑战。Armv8-R架构增加了新功能,使得能够更好地控制单个处理器中的软件,提供代码隔离,并实现可重现和可理解的行为,包括在实时处理器中引入虚拟化支持。

Cortex-R52和Cortex-R52+处理器具有高度可配置性,可以满足使用者的应用要求。其中一些可配置性在表1中描述。
 title=

作为Armv8-R架构的一部分,这些处理器提供了一个更高的异常级别EL2。 它比异常级别0(EL0)和操作系统空间——异常级别1(EL1)的异常级别更高。这个新的异常级别可以通过使用虚拟化监管程序(hypervisor)/隔离内核来帮助管理处理器上的软件,简化合作伙伴控制软件访问共享资源及其交互的方式。它可以用于在隔离同一操作系统上运行的单个处理器的任务,或隔离多个操作系统。

随着新的异常级别的引入,还增加了两级(two stage)存储保护单元(MPU),它能够限制处理器对不同资源的访问。操作系统能够在EL1级别上控制其资源的MPU(stage1 MPU),但处理器还有额外的第二级MPU(stage 2 MPU),该MPU只能由EL2进行配置,hypervisor运行在EL2。
 title=

资源的访问是由在新的更高异常级别2上运行的hypervisor软件进行管理的。应用程序任务可以通过hypervisor请求所需的资源,hypervisor使用两个级别的内存保护单元(MPU)来限制访问。这种方法不仅限于用于EL0/1和EL2异常级之间,而且可以支持许多具有不同保护的不同上下文。与内存管理单元(MMU)不同,MPU可以使Cortex-R处理器对系统资源的访问管理不需要引入额外的、可能破坏调度的延迟,来查询和加载页表。这些MMU的行为很难管理,且很难评估和保证及时完成。

MPU的两个级别是:

  • EL1 MPU,由操作系统管理,用于隔离操作系统与应用程序任务/中断服务例程之间,以及隔离应用程序任务/中断服务例程之间。EL1 MPU可以由在EL2或EL1运行的代码进行编程。
  • EL2 MPU,它只能由在EL2运行的代码进行编程,hypervisor用它提供额外的隔离。

Cortex-R52+提供了从CPU核传输到核之外的信息,以便系统对正在运行的软件进行访问的控制。这是通过广播虚拟机ID(VMID)用于设备事务来实现的,以便系统管理对这些资源的访问。对于Cortex-R52+,它进一步扩展到支持直接从EL2的hypervisor发出的缓冲区和内存传输和请求。

这些Cortex-R处理器集成了自己的通用中断控制器(GIC),cluster中所有CPU共享此GIC,以发送系统中的低延迟中断。这可以灵活地将共享外围中断(SPI)分配和优先级分配给cluster中的任何一个CPU核。GIC支持发送物理和虚拟中断,并且可以trap中断访问以在EL2上虚拟化中断。这些处理器具有紧密耦合存储(Tightly Coupled Memories,TCM),可让CPU核高度确定性地、低延迟地访问代码和数据。它们具有多个外部资源访问接口,包括SRAM、主存储器和设备。基于内存地址访问范围决定硬件使用那个接口,设计者能够灵活地分配它们所使用的内存映射空间,并管理分配资源虚拟机私用。

软件集成机制

随着车辆中的软件数量增加,越来越多的应用程序正在集成到一个微控制器上。这在域/区控制器中特别明显,它们提供了机电一体化 Rim上的简单ECU和超强中央车辆计算机(通常使用Arm Cortex-A CPU核并运行基于POSIX的操作系统和自适应AUTOSAR)之间的桥梁,而这些ECU通常使用Arm Cortex-R和Cortex-M CPU核。

虚拟化技术和虚拟机

使用Cortex-R52+的微控制器可以支持集成应用程序所需的隔离系统。每个应用程序在自己的独立实例中运行,通常称为分区或虚拟机(VM)。一个VM通常由以下组成:

  • 物理或虚拟处理器内核
  • 内存
  • 物理或虚拟外设
  • 物理或虚拟配置寄存器

管理VM的软件通常称为hypervisor(虚拟化监管程序)、隔离内核或VM管理器,它在Cortex-R处理器上运行于特权级别2(EL2)。
在不同的程度上,hypervisor让运行在虚拟机内部的guest软件产生错觉:它正在自己的微控制器上运行,并且不与其他虚拟机中的guest软件共享微控制器设备。

请注意:Armv8-R Cortex-R处理器(以及类似的设备)不提供内存管理单元(MMU)。在Cortex-A设备上运行的hypervisor可以使用其MMU为每个虚拟机呈现完全独立的虚拟地址空间。例如,运行在每个虚拟机内的guest软件可以链接到相同的地址并使用相同的内存地址范围进行数据传输。Cortex-R52+提供的内存保护单元(MPU)允许 hypervisor将一个VM的内存保护起来以防止另一个VM的干扰,但不允许每个VM具有独立的虚拟地址空间。

一个物理处理器CPU核可以通过上下文切换运行多个虚拟CPU核,就像操作系统在进程之间进行上下文切换一样。虚拟CPU核的上下文是通用寄存器、浮点寄存器、一些系统配置寄存器以及EL1 MPU的配置值。

在虚拟机中运行遗存软件时,我们希望虚拟机尽可能地看起来像一个真正的微控制器,以避免需要修改遗存软件,除重新链接之外。这样每个虚拟机中运行的guest软件就可以使用独立的内存。

使用SMPU和外设保护机制

使用Cortex-R的微控制器的系统通常会包含一个系统级内存保护单元(SMPU)。SMPU的主要作用是控制哪些总线管理器(例如DMA控制器)可以访问哪些内存地址。Cortex-R处理器CPU核和其他微控制器组件,如Cortex-M核和一些外设,可以是总线管理器。通常,SMPU具有一组区域。每个区域可配置的起始地址、大小,并分配给一个或多个总线管理器(或在更高级的设计中,分配给一个或多个使用存在Cortex-R52+ VSCTLR.VMID寄存器中的虚拟机标识符VMID的虚拟机)。总线管理器(或虚拟机)只能访问分配给它的区域内存。
微控制器还可以包括外设保护机制,以允许外设分配给总线管理器(或虚拟机)。外设被分配给一个或多个总线管理器(或虚拟机),外设保护机制则禁止任何其他总线管理器(或虚拟机)访问外围设备的寄存器。
通过使用SMPU和外设保护机制,我们可以实现cluster级别的隔离。即微控制器的内存和外设可以分区给多个虚拟机,其中一个虚拟机包含Cortex-R cluster 中的所有CPU核。仅依靠上述机制,如果虚拟机具有不同的安全级别(例如,不同的ISO 26262 ASIL级别),则不允许在同一cluster中有多个虚拟机。每个cluster都有一个通用中断控制器(GIC),用于将中断路由到cluster中的CPU核。每个核都有一个单独的GIC redistributor ,用于处理软件生成的中断(SGI)和私有外设中断(PPI),但用于处理SPI中断的GIC分配器是cluster中所有CPU核共用的。如果允许同一Cortex-R52 cluster中的多个虚拟机写入映射到内存的GIC distributor寄存器,一个虚拟机可能会通过(意外或恶意)更改其他虚拟机的中断配置来干扰另一个虚拟机。
 title=

使用SMPUs和外设保护机制的优点是可以创建包括Cortex-R52+核和其他DMA组件的虚拟机,这些组件可能存在于微控制器中并连接到相同的内存总线上。例如,微控制器可能包括一些Cortex-R52+ cluster和一些特殊用途的Cortex-M核。

利用EL2进行Para-virtualization

除了微控制器提供的SMPUs和外设保护等保护机制外,Cortex-R52+本身还包括支持虚拟化的功能。其中一个功能是EL2特权级别。EL2比操作系统使用的EL1(监管者)级别和应用程序代码使用的EL0(用户)级别有更高的特权。虚hypervisor运行在EL2上,虚拟机内的代码(即guest软件)运行在EL1或EL0上。
HVC(hypervisor call)指令可被运行在EL1的代码使用,以与应用软件使用的SVC(supervisor call)指令类似的方式向hypervisor发出请求。当运行在EL1的软件执行HVC指令时,Cortex-R52+核会切换到EL2并进行异常处理。hypervisor处理此异常,然后返回到EL1中的guest软件。

HVC让Para-virtualization成为可能。Para-virtualization是指guest软件意识到自己正在运行在虚拟机中,hypervisor提供一个API(使用HVC指令)供guest软件使用,以向hypervisor,或hypervisor中的EL2设备驱动程序,或在其他VM中运行的设备驱动程序发出请求。

想想如何使用Para-virtualization让多个虚拟机运行于同一cluster中,尽管这些虚拟机共享GIC distributer。SMPU(或CPU核的MPU)被配置为VM不能访问GIC的memory-mapped寄存器。当guest软件想要更改其中断配置时,它会向hypervisor发出API请求。hypervisor进行必要的GIC配置之前,首先检查所请求的更改是否会干扰另一个VM。

 title=

Para-virtualization也可用于允许外设共享和虚拟外设的创建。外设,例如以太网控制器,可以像GIC一样进行共享。也可以创建完全虚拟的外设。例如,可以创建一个虚拟以太网控制器,用于在同一微控制器上运行的虚拟机之间进行通信。在这两种情况下,hypervisor将包含一个EL2设备驱动程序,该驱动程序管理对共享外设的访问或实现外设虚拟化。这类似于操作系统使用设备驱动程序来管理多个进程或任务共享的外设的方式。Para-virtualization可以用作不支持或不完全支持硬件虚拟化的外设的解决方案。理想情况下,外设应支持像“实时系统的设备虚拟化原则”中描述的虚拟化,以避免需要进行Para-virtualization——至少在数据面板上。与设备直通 (pass-through,其中外设由guest软件直接驱动,而无需 hypervisor干预)相比,Para-virtualization(和陷入和模拟)不可避免增加一些额外的开销,但除非外设支持虚拟化,否则Para-virtualization(或陷入和模拟)可能需要用于允许外设在虚拟机之间共享。在仅偶尔执行Para-virtualized代码的情况下,Para-virtualization的开销可能是可以接受的,例如必须进行Para-virtualization但不需要数据面板的情况。

使用EL2进行陷入和模拟

在某些情况下,无法对guest软件进行Para-virtualization。在这些情况下,可以使用陷入和模拟。
当在EL1或EL0中运行的代码进行EL2 MPU禁止的内存访问时,Cortex-R52+处理器会切换到EL2并引发Hyp-mode entry异常。 hypervisor可以利用此功能,允许对具有memory-mapped存器的外设进行模拟访问。EL2 MPU被配置为禁止访问寄存器。当guest软件读取或写入寄存器时,会发生Hyp-mode entry异常陷入EL2。 hypervisor通过检查Cortex-R52+的Hyp Syndrome Register(HSR)(包含异常发生原因的详细信息)和Hyp Data Fault Address Register(HDFAR)(包含发生异常时被访问的内存地址),确定guest软件正在读写的寄存器,并模拟访问寄存器本身或委派给EL2设备驱动程序。
陷入和模拟可以用于访问共享的GIC distributer。EL2 MPU被配置为,guest软件访问GIC memory-mapped寄存器时会引发异常。当异常发生时, hypervisor会在首先检查寄存器访问是否会干扰另一个虚拟机之后执行GIC寄存器访问。
陷入和模拟可以为guest软件提供一种访问由EL2设备驱动程序管理的共享和虚拟外设的手段。在集成传统软件时,可以使用陷入和模拟来模拟不存在于微控制器中的外设。

Trap-and-emulate有一个优点,即客户软件不需要修改就可以在VM中运行。然而,para-virtualization通常更具有性能,因为:

  • para-virtualization可以在更高的抽象级别上请求对外设的操作,这会导致对hypervisor的较少切换(例如,我们可能设计一个“configure interrupt”操作请求,它相当于多次访问GIC寄存器)。
  • 当Hyp-mode entry异常发生时,hypervisor不必确定guest software正在做什么。

中断虚拟化

仅使用EL2不能让我们共享或虚拟化中断驱动的外设。Armv8-R架构定义,通常情况下,当发生中断时,它会中断当前特权级别下正在运行的代码。例如,如果在EL1中运行代码时发生IRQ,则使用EL1向量表中的IRQ entry在EL1中进行中断处理,但是如果在EL2中运行代码时发生IRQ,则使用EL2向量表中的IRQ entry在EL2中进行中断处理。
为了解决这个问题,Cortex-R52+支持中断虚拟化。当启用中断虚拟化时(通过设置HCR寄存器中的IMO和FMO标志并设置ICH\_HCR寄存器中的EN标志),FIQ或IRQ中断(异常)总是导致Cortex-R52+切换到EL2并使用EL2向量表进行FIQ或IRQ中断。然后,hypervisor可以处理中断或使用Cortex-R52+ CPU核的功能来虚拟化中断(使用list寄存器),以便在guest software在EL1 / EL0上运行时,它使用EL1向量表在EL1上接收虚拟中断。对于guest software,虚拟中断与实际中断无差别。当guest software禁用中断或更改优先级掩码寄存器的值时,只有路由到guest VM的虚拟中断受到影响,而不是在EL2中进行的真实中断。因此,guest software无法停止hypervisor进行的中断。
 title=

由于所有中断最初都由hypervisor处理,hypervisor可以决定是否由hypervisor本身、EL2设备驱动程序处理中断,或者将中断虚拟化并注入到VM中。这允许处理中断驱动的共享/虚拟外设。EL2设备驱动程序也可以在需要时向VM注入虚拟中断。中断虚拟化还允许“远程控制”VM。例如,运行在一个物理CPU核上的特权管理VM或EL2设备驱动程序可以在第二个物理CPU核中生成一个中断,以请求hypervisor在第二个CPU核上执行某些操作,例如关闭或重新启动在第二个CPU核上运行的VM。

当然,没有免费的午餐,中断虚拟化增加了处理中断的总时间。具体的开销取决于许多因素,包括中断到达模式以及使用多少个不同的GIC中断。在与中断虚拟化相关的时间问题上有两个需要注意的方面:

1.虚拟化中断的EL2处理会消耗处理器时间。   
2.由于虚拟中断的优先级与真实中断的优先级无关,因此guest软件可能会看到时间异常。
以下是一些例子:
考虑两个中断A和B,其中A的优先级高于B。这两个中断都使用中断虚拟化被路由到同一个VM中。
i. 如果A发生并且EL2和EL1处理A完成后,B发生,则由于EL2处理,guest软件会看到两个中断的延迟略微增加。
ii. 如果两个中断同时发生,在任何EL1处理之前,EL2先处理两个中断。guest软件将看到A的延迟加倍,但B的延迟不会增加。
iii. 现在假设A发生并到达guest软件的EL1处理程序,然后B发生。尽管A的优先级更高,但B的EL2处理会抢占A的EL1处理。

为了帮助量化这种 GIC 虚拟化行为,我们包含了使用 ETAS 的 RTA-HVR
hypervisor进行的一些实验结果。在这些实验中,我们比较了运行没有hypervisor的情况RTA-OS 操作系统的 Cortex-R52+ CPU核,和运行作为虚拟机guest软件的相同的 Cortex-R52 CPU核的延迟。使用了同一 Cortex-R cluster中的两个CPU核。第一个CPU核通过设置 GIC ISPENDR 寄存器(软件用于触发中断的set pending寄存器)触发给第二个CPU核中断。中断延迟是中断被触发到(完全由操作系统管理,即 AUTOSAR 类别 2)ISR之间的时钟数。计时器被配置为以与处理器时钟相同的速度运行。延迟值的确切数值取决于用于代码/数据的存储器类型和缓存配置,因此在以下结果中,重点是关注hypervisor和非hypervisor情况下的比较,而不是绝对值。
 title=
表2展示了当第一个CPU核触发四个不同中断,中断之间有很大的延迟,以让触发下一个中断之前第二个CPU核已经完成了所有中断处理时会发生什么。在这种情况下,我们看到中断延迟增加了约 80%。在这种情况下,操作系统配置中不包含任何不受信任的代码(即所有应用程序代码都在 EL1 上运行)。
 title=
表格3包含了与表格2相同的设置结果,只是操作系统配置包括不可信任的任务和ISR。在这种情况下,必须由RTA-OS完成的额外工作来管理不可信代码,这意味着在EL2中对中断进行虚拟化的工作在整体中的比例较小。
 title=

表格4展示了如果四个中断同时被触发会发生什么。中断号越低优先级越高。对于没有hypervisor的情况,我们看到给定中断优先级的预期行为。中断号1的ISR首先运行,并阻塞其他中断,直到它已完成。然后运行中断号2的ISR,并阻塞其他中断,直到它已完成。依此类推。中断N-1开始的ISR和中断号N开始的ISR之间的时间大约相同(执行的ISR代码很少)。然而,有了hypervisor,我们会看到非常不同的行为。在中断号1的EL1 ISR被处理之前,所有四个中断的EL2处理都已完成。因此,我们看到中断号1的中断延迟比后续中断要大得多。

虚拟处理器CPU核

我们还可以利用中断虚拟化来支持虚拟处理器CPU核。例如,定时器中断可以由
hypervisor处理,并用于驱动虚拟CPU核调度程序,该调度程序决定何时在虚拟CPU核之间进行上下文切换。由于guest软件不能阻止在EL2处进行中断,因此损坏或恶意的来宾软件无法拒绝其他guest软件的处理器时间。对于当前未运行的虚拟CPU核的中断可以进行虚拟化,在软件中排队,并在下一次运行时注入到虚拟CPU核中。
在虚拟CPU核之间切换通常涉及重新编程EL2 MPU。还需要注意协处理器14和15配置寄存器(这些寄存器用于配置处理器的各方面,例如字节顺序,是否启用cache以及是否启用EL1 MPU)。其中一些寄存器以可能会以影响所有物理CPU核和hypervisor的方式影响物理CPU核,其他寄存器则具有可能是虚拟CPU核特定的影响,例如EL1 MPU region寄存器。后一类寄存器需要成为虚拟CPU核的上下文的一部分。对于前一类的寄存器,Cortex-R52 +可以配置为在访问这些寄存器时产生Hyp-mode entry异常到EL2处理。 hypervisor可以以某种方式模拟访问这些寄存器。
 title=

如果一个物理CPU核要运行多个虚拟CPU核,那么必须考虑如何调度虚拟CPU核。最简单的方法是使用静态TDMA(时分多址)算法。TDMA算法具有非常低的运行时开销,易于理解,并且可以轻松计算出虚拟CPU核在实时时钟中的运行时间。纯静态算法的缺点是,它可能会导致在处理异步事件(例如中断)时出现较长的延迟。可以通过精心构建静态虚拟机调度来避免长时间等待中断,以确保处理它的VM不需要等待太长时间。但是,这可能需要详细了解中断最差执行时间。
处理具有短延迟的异步事件的另一种方法是使用动态调度算法。动态调度算法的一个例子是基于预留的调度,其中每个虚拟CPU核都是可推迟的服务器(Deferrable Server)。这种算法已在一些ETAS RTA-HVR hypervisor版本中使用。这样可以在处理异步事件时获得更短的延迟,但代价是更高的运行时调度开销和需要对客户操作系统进行para-virtualization,以便在操作系统没有任务运行时可以yield其虚拟CPU核。

使用虚拟处理器CPU核可以给系统设计师带来灵活性:

--可以创建一个包含比物理CPU核更多CPU核的虚拟机(VM)。额外的CPU核可能使软件的结构更容易,就像在操作系统中使用线程一样。
--单个物理CPU核可以托管多个VM。

然而,虚拟CPU核之间的上下文切换具有相当大的开销,因为hypervisor需要保存一个虚拟CPU核的通用寄存器、浮点寄存器、相关配置寄存器和EL1 MPU设置,然后重新为另一个虚拟CPU核加载这些内容。虚拟CPU核的上下文切换类似于操作系统中的进程上下文切换。

使用虚拟CPU核会影响中断延迟。使用静态调度算法,针对当前未运行的虚拟CPU核的中断直到该虚拟CPU核下一次运行时才会被处理。使用动态调度算法,该算法会自动切换到处理中断的虚拟CPU核,此时虚拟CPU核的上下文切换时间将会增加中断延迟。

系统设计师需要评估哪些应用程序可以利用虚拟处理器CPU核。如果上下文切换虚拟CPU核的开销不可接受,则系统设计师应考虑其他选项。

软件集成建议

将多个应用程序集成到微控制器中,没有“一刀切”的方法。前一部分已经概述了几种集成的机制。适当使用哪些机制将取决于正在集成的应用程序的类型。

决定是否需要虚拟处理器隔离或操作系统级别的隔离更好?

上面描述的机制让虚拟处理器创建一个假象,即guest软件具有自己的微控制器,并在运行guest软件的虚拟机之间强制隔离。如果要集成的应用程序紧密耦合(紧密耦合意味着应用程序彼此进行同步函数调用或依赖于同一调度程序调度的所有应用程序中的活动),则使用操作系统容器进行集成可能更合适。AUTOSAR操作系统允许将任务和ISR分组成称为“操作系统应用程序”的容器,并可以使用MPU分隔这些不同的容器。在操作系统级别进行集成意味着使用单个调度程序调度所有任务,并且更好地支持紧密耦合的通信。正在开发新的倡议,如AUTOSAR Flex-CP,以支持将应用程序更动态地集成到经典AUTOSAR系统中。

将每个虚拟机视为通过网络连接的单独ECU

在每个应用程序中运行虚拟机是最佳方法时,重要的是要将每个虚拟机视为通过网络连接的单独的电子控制单元(ECU)。每个虚拟机可能包含具有自己的操作系统和调度策略的guest软件。不同虚拟机之间的任务紧密耦合,无论是在调度还是通信方面,都很难管理,并且很可能导致系统脆弱。最好将每个虚拟机视为单独的ECU,并使用AUTOSAR中内置的机制来处理由多个ECU构建的系统。这会产生一个更强大、更简单、更容易理解的系统。

使用CPU核和cluster本地资源

最好使用靠近CPU核的资源,例如内存和外设。每个Cortex-R CPU核都有TCM,比其他类型的RAM更快速。通常,微控制器具有cluster本地的Flash和RAM,有些情况下外设(例如CAN和LIN控制器)可以被分配到一个cluster中。除了通常更快,使用cluster本地资源通常会导致更少的内存总线争用,因为访问cluster本地资源的CPU核可能不必与其他cluster中的CPU核竞争访问内存总线。
请注意,使用靠近CPU核的资源可能会限制虚拟处理器CPU核在运行时在物理处理器CPU核之间的任何迁移(如果支持)。例如,如果将虚拟CPU核放在到使用Cortex-R CPU核cluster0本地的FLASH,则如果迁移到cluster1,虚拟CPU核将运行更慢。

考虑中断延迟和实时要求

下表总结了适用于不同中断延迟和实时要求的应用程序的技术。更详细的讨论可以在后续的小节中找到。
 title=

超低延迟硬实时应用程序

在这里,我们考虑需要非常短和可预测中断延迟的应用程序。实质上,我们想要“bare metal”行为。在这些情况下,由于使用这些技术会导致增加且不太可预测的中断延迟,中断虚拟化和在物理CPU核上托管多个虚拟CPU核更具挑战性。
使用para-virtualization或trap-and-emulate虚拟化GIC访问将降低性能,可能适用,也可能不适用。当hypervisor代表guest软件进行GIC访问时,中断很可能会被禁用。然而,这种中断阻塞将发生在guest软件控制的时间内(例如,在初始化期间)。

相同的论点适用于使用EL2设备驱动程序共享外设和创建虚拟外设。所需的para-virtualization或trap-and-emulate相对较慢,但当发生时,它是应用程序控制的。
对于这种类型的应用程序,特别建议使用靠近CPU核或cluster的内存。

低延迟硬实时应用程序

在这里,我们考虑需要短且可预测中断延迟的应用程序,但是对于不太可预测的中断延迟是可以接受的。
根据这些类型的应用程序对中断延迟的可接受上限,如果使用合适的虚拟CPU核调度算法,则可以在一个物理CPU核上托管多个虚拟CPU核和中断虚拟化。动态调度算法,例如基于保留的服务的调度,可以导致相当短且相对可预测的中断延迟,尽管由于需要在虚拟CPU核处理中断的虚拟CPU核上下文切换,这些延迟比“bare metal”延迟长
在超低延迟的硬实时应用程序部分中讨论虚拟化GIC访问和使用EL2设备驱动程序的讨论也适用于此处。

延迟为重的实时应用程序

我们考虑的是不需要特别短的中断延迟,但需要有边界中断延迟的应用程序。同样地,取决于可接受的中断延迟上限,对于这些类型的应用程序,中断虚拟化和在物理CPU核上托管多个虚拟CPU核可能是可行的。是否使用静态或动态虚拟CPU核调度取决于中断延迟的可接受上限。如果上限相当长,那么静态调度算法可能有效。例如,如果虚拟CPU核之间调度的最长时间比中断延迟的上限更短。如果上限更短,则需要动态调度算法。

最佳努力应用程序

在最佳努力(非实时)应用程序中,将多个虚拟CPU核复用到单个物理CPU核,共享和虚拟设备支持可以更有效地利用微控制器资源。在某些领域,许多应用程序执行的功能没有硬实时约束,并且这些应用程序通常响应激励执行其功能,然后停止,直到激励再次发生。这种系统适合在单个物理CPU核上托管多个应用程序。

如果系统需要处理具有短延迟的异步事件,则可能需要使用动态虚拟核调度算法。然而,如果没有处理具有短延迟的异步事件的需求,则简单的静态调度算法将具有较低的运行时开销。

遗存/老旧(legacy)软件

在集成老旧应用程序时,希望最小化对软件的更改。如果应用程序没有硬实时约束,则可以使用上述大多数机制,但无法使用para-virtualization。Trap-and-emulate将允许使用EL2设备驱动程序来仿真老旧外设。
如果老旧应用程序具有超低延迟的硬实时要求,则唯一的解决方案可能是给应用程序一个完整的Cortex-R cluster,并使用SMPU和外设保护将该cluster与微控制器的其余部分隔离开来。

未来微控制器的建议

提供对VM的外设进行细粒度分配

如果可以对外设进行细粒度分配,则可以减少对EL2设备驱动程序的需求。例如,能够将单个CAN通道,甚至单个通用输入/输出(GPIO)引脚分配给VM将是有用的。这减少了对para-virtualization或trap-and-emulate的需求,从而提高了性能。虽然完整的外设虚拟化是理想的(见下文),但是妥协方案是使用para-virtualization/trap-and-emulate来执行外设的初始化和配置,但允许数据面板直接访问。

尽可能提供更多的MPU region

将内存或外设分配给VM通常使用大量SMPU和核MPU region。可用的(S)MPU region越多越好(这意味着芯片合作伙伴将EL2 MPU包含在设计综合中)。如果MPU region粒度小,则更好。小的MPU region粒度使分配外设给VM更容易。

支持外设虚拟化

比细粒度的外设到VM分配更好的是对外设进行完全虚拟化。在这里, hypervisor 配置外设以向多个VM呈现其单独的“视图”。然后,每个VM可以像分配了外设的唯一实例一样使用外设

确保DMA支持虚拟化

当VM使用DMA传输或使用使用DMA传输的外设时,DMA传输不能允许VM从通常受SMPU或核MPU禁止的内存地址读写。理想情况下,DMA模块/通道应自动继承配置DMA模块/通道或使用DMA模块/通道的外设的VM的身份。然后,SMPU至少会在DMA传输中检查VM标识符(VMID),如果VM没有权限读写DMA传输涉及的内存,则会阻止DMA传输。为支持此行为,应将Armv8-R VMID分配给外设和DMA控制器。
如果不可能实现自动继承VM身份,则应由特权软件实体编程地将DMA模块/标识符分配给VM,以便可以让SMPU控制的DMA传输。
当单个物理CPU核可能运行多个VM时,VM而不仅仅是总线管理器对DMA的控制很重要。

采用可用的虚拟化标准以便于软件移植

虚拟化是运行Classic AUTOSAR系统的微控制器通常使用的比较新的话题,微控制器制造商正在添加功能以获得竞争优势。然而,这些微控制器的用户希望开发软件,并有信心将该软件移植到不同的微控制器中。因此,微控制器和hypervisor的组合需要为微控制器的用户提供一组相对标准的功能和功能使用方法。为此,应采用行业标准,针对Armv8-R架构已经在此领域开展了一些工作,其中一个很好的例子可以在Arm的“Device virtualization principles for real time systems”论文中找到。

总结/结论:

EE-架构的演变,包括区控制器,需要进一步解决实时软件集成的问题。经典AUTOSAR是汽车实时软件世界的事实标准,但是未来必须提供更多的集成选项,例如用于老旧软件的选项。具有EL2隔离选项的Armv8-R架构代表了一个很好的选择,以实现智能集成选项。然而,如何使用这种集成选项高度依赖于应用程序,特定的应用程序需求将决定最适合的集成方式。本文介绍了一系列可用于支持不同类型应用程序集成的技术。这应该有助于系统设计人员了解如何最好地使用Cortex-R52+内核来支持应用程序集成。

推荐阅读
关注数
8627
内容数
50
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息