ARM处理器在移动领域已经大放异彩占据了绝对优势，但在服务器领域ARM仍处于发展上升阶段。 为了能够和X86在服务器领域展开竞争，ARM也逐渐对虚拟化扩展有了较为完善的支持。 本文的目的是介绍一下ARMv8处理器的虚拟化扩展中的一些相关知识点， 将主要从ARM体系结构、内存虚拟化、中断虚拟化、I/O虚拟化等几个方面做一些概括总结。 本文将尽可能的在特性层面将ARM和X86做一些对比，以加深我们对于ARM Virtualizaiton Extension的印象。

在进入正题之前先回顾一下ARMv8体系结构的一些基本概念。

ARMv8支持两种执行状态：AArch64和AArch32。

AArch64 64-bit执行状态：

AArch32 32-bit执行状态：

ARM 内存模型：

ARM 内存管理（参考ARM Address Translation）：

OK，假装我们现在的ARMv8-A已经有了一个初步的了解，下面再从几个大的维度去看下ARMv8对虚拟化是怎么支持的。

ARM为了支持虚拟化扩展在CPU的运行级别上引入了Exception Level（异常级别）的概念，AArch64对应的Exception Level视图如下图：

注：当CPU的Virtualization Extension被disable的时候，软件就运行在EL0和EL1上，这时候EL1有权限访问所有的硬件。

ARM的异常级别可以分为同步（synchronous）和异步(asynchronous)两类：

与ARMv8不同的是，在X86为支持CPU虚拟化引入了Root Mode和None-Root Mode的概念和一套特殊的VMX指令集， 其中非根模式是Guest CPU的执行环境，根模式是Host CPU的执行环境。 根模式、非根模式与CPU的特权级别是两个完全独立的概念，二者完全正交， 也就是说非根模式下支持和根模式下一样的用户态（Ring 3）、内核态（Ring 0）特权级。 而这和ARM是不同的，ARM CPU是依靠在不同的EL之间切换来支持虚拟化模式切换。 但二者都有一个相同点:那就是ARM和X86在虚拟化模式下如果执行了敏感指令会分别退出到EL2和Root Mode之间。 同时，X86上为了更好地支持Root/Non-root Mode在内存中实现了一个叫做VMCS的数据结构， 用来保存和恢复Root/None-root模式切换过程中的寄存器信息，VMX指令集则专门用来操作VMCS数据结构。 但在RISC-style的ARM处理器上，则没有类似的实现，而是让Hypervisor软件自己来决定哪些信息需要保存和恢复， 这在一定程度上带来了一些灵活性[Ref1]。

为了优化多个异常级别带来的虚拟化上下文切换开销，ARMv8中引入了虚拟化主机扩展特性(virtual Host Extension, VHE) Ref2。 其实现原理是直接将宿主机内核运行在EL2上。为了实现EL2引入HCR_EL2寄存器，用来控制这一特性。 VHE带来的好处是减少了2次异常级别的切换，只需要保存和恢复部分Host的上下文， 减少了虚拟化的开销，带来了性能的提升。

在ARMv8-A上，每个tarnslation regime可能包括1个stage，也可能包括2个sate。 每个Exception Level都有自己的地址翻译机制，使用不同的页表基地址寄存器，地址翻译可以细分到stage， 大部分的EL包括一个stage的地址翻译过程， Non-Secure EL1&0包括了2个stage的地址翻译过程。 每个stage都有自己独立的一系列Translation tables，每个stage都能独立的enable或者disable。 每个stage都是将输入地址（IA）翻译成输出地址（OA）[Ref3]。

所以在虚拟化场景下，ARM和X86上的方案是类似的，都是采用两阶段地址翻译实现GPA -> HPA的地址翻译过程。 虚拟机运行在None-secure EL1&0，当虚拟机内的进程访问GVA的时候MMU会将GVA翻译成IPA（intermediate physical address，中间物理地址：GPA）， 这就是所谓的stage 1地址翻译。然后MMU会再次将IPA翻译成HPA，这就是所谓的stage 2地址翻译。

在不同的Eexception Level下有不同的Address Space，那么如何去控制不同地址空间的翻译呢？

ARMv8-A上有一个TCR（Translation Control Register）寄存器来控制地址翻译。 例如：对于EL1&0来说，由于在该运行模式下VA存在2个独立的映射空间（User Space和Kernel Space）， 所以需要两套页表来完成地址翻译，这2个页表的及地址分别放在TTBR0_EL1和TTBR1_EL1中。

对于每一个地址翻译阶段:

内存虚拟化也没有太多可以说道，理解了原理之后就可以去梳理KVM相关代码，相关代码实现主要在arch/arm/mm/mmu.c里面。

设备直通的目的是能够让虚拟机直接访问到物理设备，从而提升IO性能。 在X86上使用VT-d技术就能够实现设备直通，这一切都得益于VFIO驱动和Intel IOMMU的加持。 那么在ARMv8-A上为了支持设备直通，又有哪些不同和改进呢？

同X86上一样，ARM上的设备直通关键也是要解决DMA重映射和直通设备中断投递的问题。 但和X86上不一样的是，ARMv8-A上使用的是SMMU v3.1来处理设备的DMA重映射， 中断则是使用GICv3中断控制器来完成的，SMMUv3和GICv3在设计的时候考虑了更多跟虚拟化相关的实现， 针对虚拟化场景有一定的改进和优化。

先看下SMMUv3.1的在ARMv8-A中的使用情况以及它为ARM设备直通上做了哪些改进[Ref4]。 SMMUv3规定必须实现的特性有：

SMMUv3支持的可选特性有：

我们知道，一个平台上可以有多个SMMU设备，每个SMMU设备下面可能连接着多个Endpoint， 多个设备互相之间可能不会复用同一个页表，需要加以区分，SMMU用StreamID来做这个区分， 通过StreamID去索引Stream Table中的STE（Stream Table Entry）。 同样x86上也有类似的区分机制，不同的是x86是使用Request ID来区分的，Request ID默认是PCI设备分配到的BDF号。 不过看SMMUv3 Spec，又有说明：对于PCI设备StreamID就是PCI设备的RequestID， 好吧，两个名词其实表示同一个东西，只是一个是从SMMU的角度去看就成为StreamID，从PCIe的角度去看就称之为RequestID。 同时，一个设备可能被多个进程使用，多个进程有多个页表，设备需要对其进行区分，SMMU使用SubstreamID来对其进行表示。 SubstreamID的概念和PCIe PASID是等效的，这只不过又是在ARM上的另外一种称呼而已。 SubstreamID最大支持20bit和PCIe PASID的最大宽度是一致的。

STE里面都有啥呢？Spec里面有说明：

理论上，多个设备可以关联到一个虚拟机上，所以多个STE可以共享一个stage2的翻译表。 类似的，多个设备(stream)可以共享一个stage1的配置，因此多个STE可以共享同一个CD。

Stream Table是存在内存中的一张表，在SMMU设备初始化的时候由驱动程序创建好。 Stream Table支持2种格式，Linear Stream Table 和 2-level Stream Table， Linear Stream Table就是将整个Stream Table在内存中线性展开为一个数组，优点是索引方便快捷，缺点是当平台上外设较少的时候浪费连续的内存空间。 2-level Stream Table则是将Stream Table拆成2级去索引，优点是更加节省内存。

在使能SMMU两阶段地址翻译的情况下，stage1负责将设备DMA请求发出的VA翻译为IPA并作为stage2的输入， stage2则利用stage1输出的IPA再次进行翻译得到PA，从而DMA请求正确地访问到Guest的要操作的地址空间上。

在stage1地址翻译阶段：硬件先通过StreamID索引到STE，然后用SubstreamID索引到CD， CD里面包含了stage1地址翻译（把进程的GVA/IOVA翻译成IPA）过程中需要的页表基地址信息、per-stream的配置信息以及ASID。 在stage1翻译的过程中，多个CD对应着多个stage1的地址翻译，通过Substream去确定对应的stage1地址翻译页表。 所以，Stage1地址翻译其实是一个（RequestID, PASID） => GPA的映射查找过程。 注意：只有在使能了stage1地址翻译的情况下，SubstreamID才有意义，否则该DMA请求会被丢弃。

在stage2地址翻译阶段：STE里面包含了stage2地址翻译的页表基地址（IPA->HPA）和VMID信息。 如果多个设备被直通给同一个虚拟机，那么意味着他们共享同一个stage2地址翻译页表[Ref5]。

值得注意的是：CD中包含一个ASID，STE中包含了VMID，CD和VMID存在的目的是作为地址翻译过程中的TLB Tag，用来加速地址翻译的过程。

系统软件通过Command Queue和Event Queue来和SMMU打交道，这2个Queue都是循环队列。 系统软件将Command放到队列中SMMU从队列中读取命令来执行，同时设备在进行DMA传输或者配置发生错误的时候会上报事件， 这些事件就存放在Event Queue当中，系统软件要及时从Event Queue中读取事件以防止队列溢出。

SMMU支持两阶段地址翻译的目的只有1个，那就是为了支持虚拟化场景下的SVM特性（Shared Virtual Memory）。 SVM特性允许虚拟机内的进程都能够独立的访问直通给虚拟机的直通设备,在进程自己的地址空间内向设备发起DMA。 SVM使得虚拟机里面的每个进程都能够独立使用某个直通设备，这能够降低应用编程的复杂度，并提升安全性。

为了实现虚拟化场景下的SVM，QEMU需要模拟一个vSMMU（或者叫vIOMMU）的设备。 虚拟机内部进程要访问直通设备的时候，会调用Guest驱动创建PASID Table（虚拟化场景下这个表在Guest内部）， 在这个场景下PASID将作为虚拟机内进程地址空间的一个标志，设备在发起DMA请求的时候会带上PASID Prefix，这样SMMU就知道如何区分了。 创建PASID Table的时候会访问vSMMU，这样Guest就将PASID Table的地址（GPA）传给了QEMU， 然后QEMU再通过VFIO的IOCTL调用（VFIO_DEVICE_BIND_TASK）将表的信息传给SMMU， 这样SMMU就获得了Guest内部进程的PASID Table的shadow信息，它就知道该如何建立Stage1地址翻译表了。

所以，在两阶段地址翻译场景下，Guest内部DMA请求的处理步骤

纵观SMMUv3，从设计上来和Intel IOMMU的设计和功能基本类似，毕竟这里没有太多可以创新的地方。 但ARM SMMUv3有2个比较有意思的改进点： 一个是支持Page Request Interface（PRI），PRI是对ATS的进一步改进。当设备支持PRI特性的时候， 设备发送DMA请求的时候可以缺页IOPF(IO Page Fault)，这就意味着直通虚拟机可以不需要进行内存预占， DMA缺页的时候SMMU会向CPU发送一个缺页请求，CPU建立好页表之后对SMMU进行回复，SMMU这时候再将内容写到DMA Buffer中。 另外一个改进就是，DMA写内存之后产生脏页可以由硬件自动更新Access/Dirty Bit， 这样就对直通设备热迁移比较友好，但这个功能是需要厂商选择性支持的， 而且在这种场景下如何解决SMMU和MMU的Cache一致性是最大的挑战。

ARM的中断系统和x86区别比较大，x86用的是IOAPIC/LAPIC中断系统，ARM则使用的是GIC中断控制器， 并且随着ARM的演进陆续出现了GICv2,GICv3,GICv4等不同版本， 看了GICv3手册感觉着玩儿设计得有点复杂，并不像x86上那样结构清晰。

GICv1和GICv2最大只支持8个PE，这放在现在显然不够用了。 所以，GICv3对这里进行改进，提出了affinity routing机制以支持更多的PE。

GICv3定义了以下中断类型[Ref6]： ARM上的中断类型：

ARM上的中断又可以分为两类： 一类中断要通过Distributor分发的，例如SPI中断。 另一类中断不通过Distributor的，例如LPI中断，直接经过ITS翻译后投递给某个Redistributor。

ARM上又搞出来一个Affinity Routing的概念，GICv3使用Affinity Routing来标志一个特定的PE或者是一组特定的PE， 有点类似于x86上的APICID/X2APIC ID机制。ARM使用4个8bit的域来表示affinity，格式如：

例如，现在有个ARM Big.Little架构的移动处理器SOC，拥有2个Cluster，小核心拥有4个Cortex-A53大核心拥有2个A72，那么可以表示为：

GICv3的设计上和x86的IOAPIC/LAPIC架构差异甚远，GICv3的设计架构如下图所示：

GICv3中断控制器由Distributor，Redistributor和CPU Interface三个部分组成。 Distributor负责SPI中断管理并将中断发送给Redistributor，Redistributor管理PPI，SGI，LPI中断，并将中断投递给CPU Interface， CPU Interface负责将中断注入到Core里面（CPU Interface本身就在Core内部）。

Distributor的主要功能有：

每个PE都对应有一个Redistributor与之相连，Distributor的寄存器是memory-mapped， 并且它的配置是全局生效的，直接影响所有的PE。Redistributor的主要功能有：

每个Redistributor都和一个CPU Interface相连， 在GICv3中CPU Interface的寄存器是是通过System registers(ICC_*ELn)来访问的。 在使用这些寄存器之前软件必须使能系统寄存器，CPU Interface的主要功能：

GICv3中为了处理LPI中断，专门引入了ITS（Interrupt Translation Service）组件。 外设想发送LPI中断时（比如PCI设备的MSI中断），就去写ITS的寄存器GITS_TRANSLATER，这个写操作就会触发一个LPI中断。 ITS接收到LPI中断后，对其进行解析然后发送给对应的redistributor，然后再由redistributor发送给CPU Interface。 那么这个写操作里面包含了哪些内容呢？主要是2个关键域。

ITS使用3种类型的表来完成LPI的翻译和路由：

整个流程大概是：

看来看去总觉得GICv3中断控制器设计比较复杂，不如x86上那样结构清晰，目前只是理了个大概，要深入理解再到代码级熟悉还得花不少时间。 上面说了这么多，还是在将GICv3控制器的逻辑，具体QEMU/KVM上是怎么实现的还得去看代码，为了提升中断的性能， GICv3的模拟是直接放到KVM里面实现的。比如说virtio设备的MSI中断，那肯定类型上是LPI中断，QEMU模拟的时候机制上还是使用irqfd方式来实现的， 前面也有从代码角度去分析过，后面再单独从代码层级去分析具体的实现方案。

ARM体系结构和x86存在不少差异，其中差异最大的还是中断控制器这块，这里需要投入事件好好分析一下． 内存虚拟化和I/O虚拟化这块二者可能细节上有些不同，但背后的原理还是近似的． 例如：SMMUv3在设计上和Intel IOMMU都支持了二次地址翻译，但SMMU有针对性的改进点． 更多的详细的ARM虚拟化知识和细节需要阅读ARMv8的spec文档深入去了解。