参考Armv8-A virtualization1、ARMv8 Virtualization Extension OverviewARMv8 为了支持虚拟化扩展在 CPU 的运行级别上引入了 Exception Level异常级别的概念AArch64 对应的 Exception Level 视图如下图EL0用户态程序的运行级别Guest 内部的 App 也运行在这个级别EL1内核的运行级别Guest 的内核也运行在这个级别EL2Hypervisor 的运行级别Guest 在运行的过程中会触发特权指令后陷入到 EL2 级别将控制权交给 HypervisorEL3Monitor ModeCPU 在 Secure World 和 Normal World 直接切换的时候会先进入 EL3然后发生 World 切换注当 CPU 的 Virtualization Extension 被 disable 的时候软件就运行在 EL0 和 EL1 上这时候 EL1 有权限访问所有的硬件。2、Stage 2 translation2.1 What is stage 2 translation在 ARMv8-A 上每个地址翻译域Translation Regime可能包括 1 个 stage也可能包括 2 个 stage。 每个异常级别 Exception Level都有自己的地址翻译机制使用不同的页表基地址如 TTRBx_ELx寄存器。通常情况下大部分 EL 仅包含一个 stage 的翻译过程 而 Non-Secure EL10 包括了 2 个 stage 的地址翻译过程。 每个 stage 都有自己独立的一系列 Translation tables每个 stage 都能独立的 enable 或者 disable。 每个 stage 都是将输入地址IA翻译成输出地址OA。VA (Virtual Address) 指令中使用的地址如数据或指令地址即虚拟地址。IPA (Intermediate Physical Address) 中间物理地址。如果不使能 Stage 2 翻译IPA 即为最终的物理地址PA。PA (Physical Address) CPU 发送给内存控制器的最终物理地址。在虚拟化场景下ARM 的解决方案与 x86 类似均采用了两阶段地址翻译来实现从客户机虚拟地址GVA到宿主机物理地址HPA的映射。其核心流程如下stage 1 翻译GVA - GPA 虚拟机运行在 Non-secure EL10。当虚拟机内的进程访问其虚拟地址GVA时MMU 会将其翻译为中间物理地址IPA在虚拟化语境下通常称为客户机物理地址GPA。这一过程由虚拟机的页表控制负责将客户机视角的虚拟内存映射到客户机视角的物理内存。stage 2 翻译GPA - HPA 随后MMU 会再次介入将 IPAGPA翻译为宿主机的物理地址HPA。这一过程由 Hypervisor 控制的 Stage 2 页表完成。 为什么需要 stage 2你可能会问stage 1 翻译已经将虚拟地址映射到了“物理地址”为什么还需要 stage 2答案在于安全与隔离。stage 1 翻译完全由虚拟机内部控制它产生的“物理地址”即 GPA/IPA只是 hypervisor 分配给它的“影子地址”。如果缺乏 stage 2 的介入虚拟机可能会试图访问真实的硬件资源或者越界访问其他虚拟机的内存。因此stage 2 转换的存在是为了让 hypervisor 能够掌握最终解释权控制虚拟机的内存视图。stage 2 转换允许 hypervisor 精确地控制虚拟机的内存视图。具体而言hypervisor 可以决定哪一块真实的系统资源允许 VM 访问以及这些资源在 VM 看来位于哪一块地址空间。这种对内存访问的精细控制对于实现系统的隔离性Isolation和沙盒Sandbox特性至关重要。通过 stage 2 转换系统能够确保 VM 只能访问到被明确分配给它的物理资源从而保障了整个系统的安全。2.2 TTBRx_ELx register了解了 stage 1 和 stage 2 的翻译流程后我们不禁要问硬件 MMU 是如何知道去哪里查找这些转换表的呢这就涉及到了页表基地址寄存器TTBR。这些寄存器保存了各级页表的起始物理地址是地址翻译过程的“指路牌”。在 ARMv8 的地址翻译机制中Translation Table Base Register (TTBR)扮演着至关重要的角色。它存储了当前翻译表层级结构Translation Table Hierarchy在内存中的起始物理地址。根据不同的异常级别Exception Level和翻译阶段stageARMv8 定义了不同的TTBR寄存器来分别管理页表基地址TTBR0_EL1 / TTBR1_EL1用于 stage 1 翻译运行在 EL1通常是操作系统内核。ARMv8 将虚拟地址空间分为两部分TTBR0_EL1通常指向低地址区域的页表而TTBR1_EL1指向高地址区域的页表就是常说的 Linux 中的 User Space 和 Kernel Space。TTBR0_EL2用于 stage 1 翻译运行在 EL2Hypervisor。当 EL2 自身需要访问内存时例如 Hypervisor 自己的代码和数据使用此寄存器。TTBR0_EL3用于 stage 1 翻译运行在 EL3安全监控模式。VTTBR_EL2(Virtualization Translation Table Base Register)这是虚拟化扩展引入的关键寄存器。它专门用于 stage 2 翻译。hypervisor 通过配置VTTBR_EL2告诉硬件去哪里查找 stage 2 的页表从而完成从 IPA 到 HPA 的转换。通过灵活配置这些寄存器ARMv8 能够支持复杂的虚拟化内存管理确保每个层级都能独立且正确地管理其地址空间。2.3 VMIDs上文提到的VTTBR_EL2寄存器不仅保存了 stage 2 页表的基地址它还承载着另一个关键信息——虚拟机标识符VMID。在虚拟化环境中仅仅知道页表位置是不够的Hypervisor 还需要一种机制来高效地区分不同虚拟机的地址翻译缓存TLB 表项。这就是 VMID 的作用所在。在虚拟化场景下多个虚拟机VM共享同一个物理处理器核心。如果每次发生虚拟机切换Context Switch时都强制刷新翻译后备缓冲器TLB将会带来巨大的性能开销。为了解决这个问题ARMv8 引入了 VMID 机制。VMID 的作用VMID 被用来标记 TLB 中的条目。当 MMU 进行 stage 2 地址翻译时硬件会自动比对“当前VTTBR_EL2寄存器中的 VMID” 与 “TLB 条目中记录的 VMID”。隔离性 只有 VMID 匹配的 TLB 条目才会被使用从而确保了不同虚拟机之间的地址翻译互不干扰。性能优化 这种标记机制允许不同虚拟机的翻译条目同时存在于 TLB 中。这意味着在虚拟机切换时无需刷新 TLB极大地降低了上下文切换的开销。VMID 存储在VTTBR_EL2寄存器的特定比特位中。根据 ARM 架构的版本VMID 的长度有所不同Armv8.0 支持 8 位 VMID。Armv8.1-A 及以后 增加了对 16 位 VMID 的可选支持这允许系统中支持更多的虚拟机而无需重新分配 ID。VMID 的具体行为如 8 位或 16 位模式通常由VTCR_EL2虚拟化翻译控制寄存器中的VS位进行控制。2.4 VMID interaction with ASIDs在讨论完用于隔离虚拟机的 VMID 后我们还需要关注另一个用于隔离用户进程的机制——地址空间标识符ASID。虽然 VMID 解决了不同虚拟机之间的缓存冲突但在虚拟机内部操作系统同样需要高效地管理多个应用程序的并发运行这就是 ASID 发挥作用的地方。ASID 的作用TLB 条目不仅可以被 VMID 标记还可以被 ASID 标记。ASID 通常由操作系统分配给应用程序所有属于该应用程序的 TLB 条目都会被标记上这个 ASID。进程级隔离 这意味着不同应用程序的 TLB 条目可以在 TLB 中共存而不会发生冲突。当进程切换时操作系统只需更新TTBR0_EL1中的 ASID而无需刷新整个 TLB从而显著提高了上下文切换的性能。层级关系 你可以将 ASID 理解为“进程ID”的硬件缓存标签而 VMID 则是“虚拟机ID”的硬件缓存标签。VMID 与 ASID 的协同每个虚拟机都有自己独立的 ASID 命名空间。例如虚拟机 A 和虚拟机 B 可能都使用了 ASID 5但它们指向的是完全不同的进程地址空间。因此在支持虚拟化的 ARM 系统中真正唯一标识一个 TLB 条目的是 ASID 和 VMID 的组合。硬件逻辑 硬件在进行 TLB 查找时会同时检查 VMID确保属于当前虚拟机和 ASID确保属于当前进程。寄存器配合VMID 存储在VTTBR_EL2中由 Hypervisor 管理。ASID 存储在TTBR0_EL1中由虚拟机内部的操作系统管理。这种双层标记机制VMID ASID使得 ARM 处理器能够在多级虚拟化环境中实现极高效率的 TLB 管理和上下文切换。2.5 Attribute combining and overridingstage 1 和 stage 2 映射都包含属性例如存储类型访问权限等。内存管理单元MMU会将两个阶段的属性整合成一个最终属性整合的原则是选择更有限制的属性。MMU 的合并原则是“取其严者”也就是选择限制性更强的那个属性。正如你在这里看到的例子在这个示例中Device设备类型的限制性要强于 Normal普通类型。因此最终合并出的类型就是 Device。即使我们将示例反过来让第一阶段 Normal第二阶段 Device最终的结果依然是一样的。这种属性合并机制适用于绝大多数使用场景但在某些特定情况下Hypervisor 可能希望打破这种常规行为。例如在虚拟机VM的早期启动阶段。针对这些情况系统提供了一些控制位来覆盖默认行为HCR_EL2.CD: 控制所有 stage 1 属性为 Non-cacheable。HCR_EL2.DC强制所有 stage 1 属性为 NormalWrite-Back Cacheable。HCR_EL2.FWB (Armv8.4-A引入)使用 stage 2 属性覆盖 stage 1 属性而不是使用默认的限制性整合原则2.6 Emulating Memory-mapped Input/Output (MMIO)与物理机器的物理地址空间类似VM 的 IPA 地址空间包含了内存与外围设备两种区域。如下图所示虚拟机可以利用外设区域来访问两种设备一种是真实存在的物理外设通常称为“直通设备”另一种是“虚拟外设”。虚拟外设完全由 Hypervisor 通过软件模拟实现正如下面的图示所强调的直通设备是指已经分配给虚拟机并映射到其地址空间中的真实物理设备。这使得运行在虚拟机内的软件可以直接与该外设进行交互。虚拟外设则是由 Hypervisor 通过软件模拟的设备。在地址转换的第二阶段页表中对应虚拟外设的表项会被标记为“触发异常”。虚拟机中的软件认为自己正在直接与外设通信但每一次访问都会触发第二阶段异常随后由 Hypervisor 在异常处理程序中模拟该外设的访问行为。为了模拟一个外设Hypervisor 不仅需要知道访问了哪个外设还需要知道访问了该外设中的哪个寄存器、是读操作还是写操作、访问的数据大小以及用于传输数据的寄存器信息。首先是地址信息。在异常模型中我们介绍了FAR_ELx寄存器。在处理第一阶段异常时这些寄存器会报告触发异常的虚拟地址。但这对 Hypervisor 来说帮助不大因为 Hypervisor 通常不知道客户机操作系统是如何配置其虚拟地址空间的。而对于第二阶段异常还有一个额外的寄存器HPFAR_EL2它会报告导致异常的中间物理地址IPA。由于中间物理地址空间是由 Hypervisor 控制的因此它可以利用这一信息来确定需要模拟的是哪个寄存器。异常模型展示了ESR_ELx寄存器如何报告异常信息。对于那些触发第二阶段异常的、涉及单个通用寄存器的加载或存储操作系统会提供额外的“综合征信息”。这些信息包括访问的数据大小以及源寄存器或目标寄存器使 Hypervisor 能够确定对虚拟外设进行的是何种类型的访问。关于 ESR_ELx 寄存器后面章节会有详细介绍这个寄存器很重要下图说明了“捕获并模拟访问”的整个过程这一过程可以通过以下步骤来描述虚拟机内的软件尝试访问虚拟外设。在本例中目标是虚拟 UART 的接收 FIFO先入先出队列。该访问请求在第二阶段地址转换时被拦截导致产生一个路由到 Hypervisor 的异常。a. 该异常会自动向ESR_EL2寄存器写入有关异常的信息包括访问的字节数、目标寄存器以及操作类型是加载还是存储。b. 该异常还会自动向HPFAR_EL2寄存器写入导致中止的访问所对应的 IPA。Hypervisor 利用来自ESR_EL2和HPFAR_EL2的信息来识别被访问的虚拟外设寄存器。这些信息使 Hypervisor 能够模拟该操作模拟操作就会把 Hypervisor 想让 vCPU 看到的结果写到 x0 中随后通过ERET指令返回到虚拟 CPU。c. 系统从触发异常的 LDR加载指令的下一条指令处恢复执行。2.7 System Memory Management Units (SMMUs)到目前为止我们主要讨论了源自处理器的各类内存访问。然而系统中的其他总线主控设备masters例如 DMA 控制器也可能被分配给虚拟机VM使用。因此我们需要一种方法将第二阶段stage 2的内存保护机制同样扩展到这些设备上。非虚拟化环境下的 DMA考虑一个未启用虚拟化的系统中的 DMA 控制器。该控制器通常由内核空间的驱动程序进行编程配置。内核驱动能够确保不违反操作系统级别的内存保护策略这意味着普通应用程序无法利用 DMA 越权访问其本不应看到的内存区域。虚拟化环境下的挑战现在让我们看看在虚拟机中运行操作系统的情况。此时Hypervisor 利用 stage 2 地址转换来提供 VM 之间的隔离软件对内存的可见性完全受限于 Hypervisor 控制的 stage 2 页表。允许 VM 内的驱动程序直接与 DMA 控制器交互会引发两大核心问题隔离性IsolationDMA 控制器本身不受 stage 2 页表的约束。如果缺乏额外保护它可能被用来突破 VM 的沙箱限制访问宿主机或其他 VM 的内存。地址空间不一致Address space在两级地址转换架构下VM 内核所认为的“物理地址PA”实际上是“中间物理地址IPA”。然而DMA 控制器看到的仍然是真实的系统物理地址PA。这导致内核与 DMA 控制器对内存的认知出现了偏差。为了解决这个问题Hypervisor 可以拦截trapVM 与 DMA 之间的每一次交互并进行地址转换。但在内存碎片化严重的情况下这种拦截模拟的方式效率极低且难以维护。SMMU/IOMMU硬件层面的解决方案与其通过软件拦截和模拟驱动程序的访问更优的替代方案是将 stage 2 的保护机制扩展到包括 DMA 在内的其他主控设备。这就要求这些设备也配备 MMU即所谓的系统内存管理单元SMMU在业界也常被称为 IOMMU。Hypervisor 将负责配置 SMMU使得上游主控设备如本例中的 DMA看到的内存视图与其所分配的 VM 完全一致。这一机制完美解决了上述两个难题SMMU 能够强制执行 VM 间的隔离确保外部主控设备无法被利用来突破沙箱。SMMU 为 VM 内的软件和分配给该 VM 的外部主控设备提供了一致且统一的内存视图。值得注意的是虚拟化并非 SMMU 的唯一应用场景但由于篇幅所限本指南将不涵盖其他非虚拟化用例。3、Trapping and emulation of instructions在某些情况下Hypervisor 需要对虚拟机VM内部的操作进行模拟。例如VM 内的软件可能会尝试配置与电源管理或缓存一致性相关的底层处理器控制寄存器。通常情况下我们绝不能赋予 VM 直接访问这些控制的权限因为这可能会被利用来破坏隔离性甚至影响系统中的其他 VM。什么是陷阱陷阱是一种机制当执行特定动作例如读取某个寄存器时会强制触发一个异常。Hypervisor 需要利用这种能力来拦截 VM 中配置底层控制的操作并在不干扰其他 VM 的前提下对其进行模拟。ARM 架构包含陷阱控制功能用于拦截 VM 内的操作并由 Hypervisor 进行模拟。一旦设置了陷阱执行原本被允许的操作就会触发异常并将控制权移交给更高异常级别Exception Level的软件。Hypervisor 正是利用这些陷阱来实现对 VM 内部操作的模拟。实例解析WFI 指令以执行“等待中断WFI”指令为例。通常情况下执行该指令会让 CPU 进入低功耗状态。机制通过置位HCR_EL2.TWI位即设置HCR_EL2.TWI1当 EL0 或 EL1 级别执行 WFI指令时CPU 不会进入休眠而是会触发一个异常并跳转到 EL2。应用在虚拟机环境中客户机操作系统Guest OS通常会在空闲循环中执行 WFI 指令。如上图所示Hypervisor 可以拦截这一操作并利用这段空闲时间在物理 CPU 上调度另一个虚拟 CPUvCPU运行从而极大地提高了资源利用率。注意陷阱机制并非专为虚拟化设计系统中也存在由 EL3 和 EL1 控制的陷阱。然而陷阱对于虚拟化软件而言尤为关键。本指南将仅讨论那些通常与虚拟化相关的陷阱。3.1 Presenting virtual values of registers利用陷阱机制的另一个典型示例是呈现寄存器的“虚拟值”。例如ID_AA64MMFR0_EL1寄存器用于报告处理器对内存系统相关特性的支持情况。操作系统通常会在启动阶段读取此寄存器以确定在内核中启用哪些特性。而 Hypervisor 可能希望向客户机操作系统呈现一个不同的值即所谓的“虚拟值”。为了实现这一点Hypervisor 会启用针对该寄存器读取操作的陷阱。当触发陷阱异常时Hypervisor 会判断是哪个陷阱被触发随后模拟该操作。在此示例中Hypervisor 会将ID_AA64MMFR0_EL1的虚拟值填充到目标寄存器中如下所示陷阱机制也可用于惰性上下文切换。例如操作系统通常会在启动期间初始化内存管理单元配置寄存器TTBRn_EL1、TCR_EL1和MAIR_EL1此后便不再重新编程它们。Hypervisor 可以利用这一特性来优化其上下文切换例程即在上下文切换时仅恢复这些寄存器而无需保存它们。然而操作系统可能会在启动后执行某些非常规操作并重新编程这些寄存器。为了避免由此引发问题Hypervisor 可以设置HCR_EL2.TVM陷阱。该设置会导致任何对内存管理单元MMU相关寄存器的写入操作都生成一个进入 EL2 的陷阱从而允许 Hypervisor 检测是否需要更新其保存的这些寄存器副本。注意ARM 架构使用“陷阱trapping”和“路由routing”这两个术语来指代独立但相关的概念。回顾一下陷阱是指在执行给定操作例如读取寄存器时引发异常。而路由则是指异常生成后被路由到的异常等级3.2 MIDR and MPIDR利用陷阱机制来虚拟化某个操作需要消耗大量的计算资源。该过程涉及操作触发进入 EL2 的陷阱异常随后 Hypervisor 需判定所需操作、执行模拟最后再返回客户机。像ID_AA64MMFR0_EL1这样的特性寄存器操作系统访问频率并不高。这意味着通过陷阱将这些寄存器的访问拦截至 Hypervisor 进行模拟读取其计算开销是可以接受的。然而对于那些访问频繁或处于性能关键代码路径中的寄存器你需要避免此类计算负载。这类寄存器及其值的示例包括MIDR_EL1处理器类型例如 Cortex-A53MPIDR_EL1亲和性信息例如处理器 2 的核心 1Hypervisor 可能希望客户机操作系统看到这些寄存器的虚拟值但又无需对每次访问都进行陷阱拦截。针对这些寄存器架构提供了一种替代陷阱的机制VPIDR_EL2这是针对 EL1 读取MIDR_EL1时应返回的值。VMPIDR_EL2这是针对 EL1 读取MPIDR_EL1时应返回的值。Hypervisor 可以在进入虚拟机之前配置这些寄存器。如果虚拟机内部运行的软件读取MIDR_EL1或MPIDR_EL1硬件将自动返回虚拟值而无需触发陷阱。注意VMPIDR_EL2 和 VPIDR_EL2 没有定义的复位值。它们必须在首次进入 EL1 之前由启动代码进行初始化。这在裸机环境中尤为重要4、Virtualizing the Generic Timers4.1 Physical Genertic Timers核心寄存器组成与架构视图ARM 物理定时器架构分为全局系统计数器和每核私有定时器两部分。主要涉及以下几类寄存器控制寄存器 CNTP_CTL_EL0——【每核私有】负责定时器的启停控制管理中断状态和屏蔽提供定时器状态查询比较值寄存器 CNTP_CVAL_EL0——【每核私有】存储 64 位比较值与物理计数器比较产生中断支持原子更新操作定时值寄存器 CNTP_TVAL_EL0——【每核私有】提供 32 位递减视图简化定时器编程接口自动转换为比较值物理计数寄存器 CNTPCT_EL0—— 【全局唯一】64 位单调递增计数器频率通常为1-50 MHz提供系统时间基准注意虽然寄存器的后缀是 _EL0但是 EL1 等更高层级都是可以正常访问的主要原理两种使用方式绝对时间触发中断使用CNTPCT_EL0、CNTP_CVAL_EL0寄存器。CNTPCT_EL0寄存器按照相应的时钟频率单调递增。当其值大于或等于CNTP_CVAL_EL0寄存器中的值时便会触发中断。软件通过写入CNTP_CVAL_EL0寄存器来设定中断触发时间相对时间触发中断使用CNTPCT_EL0、CNTP_TVAL_EL0寄存器。CNTPCT_EL0寄存器按照相应的时钟频率单调递增。软件写CNTP_TVAL_EL0寄存器的值 X 时硬件会自动执行以下操作读取当前的系统计数值 (CNTPCT_EL0)。计算一个绝对的目标时间目标时间 当前系统计数值 X。将这个计算出的“目标时间”自动写入到CNTP_CVAL_EL0寄存器中4.2 Virtual Generic Timers下图展示了一个托管两个虚拟 CPU 的 Hypervisor 系统示例注意在此示例中我们忽略了 Hypervisor 在虚拟 CPU 之间进行上下文切换的开销。经过 4ms 的物理时间即挂钟时间后每个虚拟 CPU 各运行了 2ms。如果虚拟 CPU0 在 T0 时设置其比较器以在 3ms 后生成中断你预期该中断会触发吗或者你是希望在虚拟时间即虚拟 CPU 所经历的时间2ms 后触发中断还是在挂钟时间 2ms 后触发Arm 架构提供了实现这两种计时的能力具体取决于虚拟化的用途。让我们来看看它是如何做到的。运行在虚拟 CPU 上的软件可以访问两个定时器EL1 物理定时器4.1 小节所讲的物理定时器EL1 虚拟定时器CNTV_CVAL_EL0, Counter-timer Virtual Timer CompareValue registerCNTV_TVAL_EL0, Counter-timer Virtual Timer TimerValue registerCNTVCT_EL0, Counter-timer Virtual Count registerHypervisor 也有自己的定时器CNTHP_CVAL_EL2, Counter-timer Hypervisor Physical Timer CompareValue registerCNTHP_TVAL_EL2, Counter-timer Hypervisor Physical Timer TimerValue register从这里也可以看出只有 CNTPCT_EL0 只读寄存器的时间是全局唯一物理时间是墙上时间且 EL0、EL1、EL2 都可以访问EL1 虚拟定时器与一个虚拟计数值CNTVCT_EL0进行比对。该虚拟计数值等于物理计数值CNTPCT_EL0减去一个偏移量CNTVOFF_EL2。CNTVCT_EL0, Counter-timer Virtual Count register可以看到这寄存器是只读寄存器。该寄存器的值 CNTPCT_EL0寄存器的值 -CNTVOFF_EL2寄存器的值。Hypervisor 的核心职责就是管理CNTVOFF_EL2寄存器以此来为每个虚拟机创造独立且连续的时间视图隐藏虚拟 CPU 未被调度运行期间的时间流逝。创建虚拟机当一个虚拟机启动时Hypervisor 会读取当前的物理时间CNTPCT_EL0然后将CNTVOFF_EL2设置为相同的值。根据上面的公式虚拟机读到的CNTVCT_EL0初始值就是 0仿佛它从一个干净的时间起点开始运行。暂停与恢复这是虚拟化时间管理最巧妙的地方。当虚拟机被暂停时Hypervisor 会记录下当时的物理时间。当虚拟机被恢复时Hypervisor 会计算从暂停到恢复这段时间物理世界流逝了多久然后更新CNTVOFF_EL2的值抵消掉这段“暂停”的时间。通过这种方式虚拟机完全感知不到自己曾被暂停过它看到的CNTVCT_EL0时间流是平滑、连续的这保证了其内部应用如数据库、定时任务的稳定运行。注意ARM 架构只是提供这种功能。具体是否使用要根据软件设计者的需求。例如某些虚拟化架构根本用不到CNTVOFF_EL2直接使用CNTPCT_EL0寄存器值即可。5、ARMv8 异常处理关键寄存器EL2 视角ELR_EL2 Exception Link Register作用保存发生异常时的下一条指令地址用于异常处理完成后返回使用方式异常进入 EL2 时自动写入返回时通过 ERET 使用典型场景Hypervisor 捕获 trap 后处理完再返回 GuestESR_ELx Exception Syndrome Register作用描述异常类型 具体原因是异常分析最关键的寄存器关键字段ECException Class异常大类如 SVC、Data Abort、HVC 等ISSInstruction Specific Syndrome更细节的信息如访问权限、指令编码等可以理解为“为什么会触发异常”举例Guest 执行 HVC → trap 到 EL2非法内存访问Data Abort执行特权指令ECException Class异常类型。表示当前产生异常的原因。例如EC 000001Trapped WFI or WFE instruction executionEC 010101SVC instruction execution in AArch64 stateEC 010110HVC instruction execution in AArch64 stateEC 100100Data Abort from a lower Exception levelEC 100000Instruction Abort from a lower Exception level… …ISSInstruction Specific Syndrome指令特征码用于记录异常发生的具体诊断信息或被拦截指令的操作参数以辅助异常处理程序精准定位原因或模拟执行。例如ISS encoding for an exception from SMC instruction execution in AArch64 state保存 SMC 指令的参数ISS encoding for an exception from a Data Abort保存产生异常时的详细信息。包括DFSC (Data Fault Status Codebit[5:0])数据故障状态码指出具体的错误原因如翻译错误、权限错误、地址大小错误等。WnR (Write not Readbit[6])指示该异常是由写操作1还是读操作0引起的。SAS (Size of Access)指示发生异常时的数据访问大小如字节、半字、字等… …FAR_EL2 Fault Address Register作用保存导致异常的内存地址只在某些异常有效Data AbortInstruction Abort可以理解为“访问哪个地址出问题了”