[V-03] 虚拟化基础-指令集架构(ISA)(基于AArch64)_aarch架构向量化指令集选项

ver 0.3

更多精彩内容，请关注公众号

前言

前面文章已经介绍了CPU的基础概念，为我们进一步研究虚拟化技术的一个最重要分支vCPU奠定了基础。回顾前文，我们知道一个CPU-Core的最根本任务就是执行指令，包括取指-执行-访存-回写，如图1-1所示。

图1-1 Cortex pipeline

为什么要了解和学习指令集(ISA)，先看一段ARM官方的说法

Why you should care about the ISA
As developers, you may not need to write directly in assembler in our day-to-day role. However, assembler is still important in some areas, such as the first stage boot software or some low-level kernel activities.
Even if you are not writing assembly code directly, understanding what the instruction set can do, and how the compiler makes use of those instructions, can help you to write more efficient code. It can also help you to understand the output of the compiler. This can be useful when debugging.

对于一名辛勤搞虚拟化开发的码农来说，虚拟化相关的代码主要由3部分组成：Hypervisor、VM、GuestOS。要写出高效的，性能良好的虚拟化代码，也一定要了解到底什么是ISA。
指令集对于CPU就是一串机器码表征的高低电平信号，对于程序员来说就是相对比较友好的汇编指令集合。先看两段代码让大家有一个直观的感受。
test.c语言代码：

#include <stdio.h>
#include <string.h>

static char *TAG = "[TEST]";

int add(int a, int b)
{
	return a+b;
}

int main(void)
{
	int para1 = 1, para2 = 2;
	int result;
	result = add(para1, para2);
	printf(" %s %s --in--\n", TAG, __func__);
	return 0;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

test.c对应的test.s汇编代码：

	.arch armv8-a
	.file	"test.c"
	.text
	.section	.rodata
	.align	3
.LC0:
	.string	"[TEST]"
	.data
	.align	3
	.type	TAG, %object
	.size	TAG, 8
TAG:
	.xword	.LC0
	.text
	.align	2
	.global	add
	.type	add, %function
add:
.LFB0:
	.cfi_startproc
	sub	sp, sp, #16
	.cfi_def_cfa_offset 16
	str	w0, [sp, 12]
	str	w1, [sp, 8]
	ldr	w1, [sp, 12]
	ldr	w0, [sp, 8]
	add	w0, w1, w0
	add	sp, sp, 16
	.cfi_def_cfa_offset 0
	ret
	.cfi_endproc
.LFE0:
	.size	add, .-add
	.section	.rodata
	.align	3
.LC1:
	.string	" %s %s --in--\n"
	.text
	.align	2
	.global	main
	.type	main, %function
main:
.LFB1:
	.cfi_startproc
	stp	x29, x30, [sp, -32]!
	.cfi_def_cfa_offset 32
	.cfi_offset 29, -32
	.cfi_offset 30, -24
	mov	x29, sp
	mov	w0, 1
	str	w0, [sp, 28]
	mov	w0, 2
	str	w0, [sp, 24]
	ldr	w1, [sp, 24]
	ldr	w0, [sp, 28]
	bl	add
	str	w0, [sp, 20]
	adrp	x0, TAG
	add	x0, x0, :lo12:TAG
	ldr	x1, [x0]
	adrp	x0, __func__.0
	add	x2, x0, :lo12:__func__.0
	adrp	x0, .LC1
	add	x0, x0, :lo12:.LC1
	bl	printf
	mov	w0, 0
	ldp	x29, x30, [sp], 32
	.cfi_restore 30
	.cfi_restore 29
	.cfi_def_cfa_offset 0
	ret
	.cfi_endproc
.LFE1:
	.size	main, .-main
	.section	.rodata
	.align	3
	.type	__func__.0, %object
	.size	__func__.0, 5
__func__.0:
	.string	"main"
	.ident	"GCC: (Arm GNU Toolchain 12.3.Rel1 (Build arm-12.35)) 12.3.1 20230626"
	.section	.note.GNU-stack,"",@progbits
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82

不同的编译器版本或者编译选项不同，编译出来的代码可能会有一些区别，但总体不会有大的变化。开头不带“.”，结尾不带“:”都是arm的指令，它们是最接近CPU且人类能够看懂的编程语言了。在这些指令面前，其他编程语言其实都算是高级语言了，而所有的高级语言都需要先编译或者在运行时被解析成体系相关的指令才能够让CPU识别并执行。遗憾的是，这些汇编指令虽然执行效率很高，但是在开发过程中的效率却是非常低的，一般只在编写体系相关和运行效率要求极高的场景下才会用到，在虚拟化场景下，很多Hypervisor核心的代码也是用汇编语言直接编辑的，例如GuestOS和Hypervisor执行上下文的快速切换。
作为硬件体系的重要组成部分，我们必须对指令集架构ISA有基本的了解。

正文

1. ISA

1.1 概念

关于指令集的架构，这里先引用一段ARM的官方的阐述：

An Instruction Set Architecture (ISA) is part of the abstract model of a computer. It defines how software controls the processor.
The Arm ISA allows you to write software and firmware that conforms to the Arm specifications. This mean that, if your software or firmware conforms to the specifications, any Arm-based processor will execute it in the same way.

我们可以将指令集架构(Instruction Set Architecture，简称ISA)看成一座沟通CPU和软件之间的桥梁。ISA包含指令集、特群集、寄存器、执⾏模式、安全扩展、性能加速扩展等⽅⾯。其中，指令集是ISA的重要组成部分，通常包含⼀系列不同功能的指令，⽤于数据搬移、计算(位、整型、浮点、向量、矩阵)、内存访问、分支控制、过程调⽤等。

指令集合的分类

我们已经知道CPU在运⾏操作系统或者应⽤程序的时候，实际上是在执⾏它被编译后所包含的指令。根据执⾏指令的特征，CPU分为精简指令集计算机(Reduced Instruction Set Conputer，简称RISC)和复杂指令集计算机(Complex Instruction Set Conputer，简称CISC)。下面通过一张图，看一下两者的区别，同样是mov相关功能的指令，CISC明显在数量和操作数的规则上要复杂的多，如图1-2所示。

图1-2 RISC vs CISC

CISC

CISC具有⼤量的指令和寻址⽅式，那么就需要更多的解释器。
CISC具有如下显著特点：
(1) 指令格式不固定，指令⻓度不⼀致，操作数可多可少；
(2) 寻址⽅式复杂多样，以利于程序的编写；
(3) 采⽤微程序结构，执⾏每条指令均需完成⼀个微指令序列；
(4) 每条指令需要若⼲个机器周期才能完成，指令越复杂，花费的机器周期越多。

RISC

RISC具有如下显著特点：
(1)RISC指令数⽬少，在通道中只包含最有⽤的指令；
(2)执⾏时间短，确保数据通道快速执⾏每⼀条指令；
(3)使CPU硬件结构设计变得更为简单；
(4)每条指令都采⽤标准字⻓。

简单总结一下：RISC类CPU的指令功能单纯，种类少；相对地，CISC类CPU指令功能复杂，种类繁多。RISC指令精简的好处是CPU内部架构可以简化，适合⾼速操作，但是在进⾏相同的操作时，由于每条指令功能单纯，所以与CISC相⽐，RISC需要使⽤更多的指令数量。虽然CISC的内部构造复杂不适合⾼速操作，但进⾏相同处理时指令数⽐RISC要少。RISC和CISC两种架构各有所⻓，在追求⾼速运⾏的CPU领域中，RISC被认为更具优势。具体ISA的选择，要看使用的场景，例如多数的嵌入式设备使用场景，RISC的指令集更加合适。而从功耗的角度分析，要支持CISC，那么CPU的微架构就会非常复杂，除了芯片成本更高之外，功耗也会非常大。而根据8/2原则，80%的程序只使⽤20%的指令，⼤多数程序只使⽤少量的指令就能够运⾏，那么就给RISC在一些场景下留下了生存的空间。ARM体系的指令集，都是RISC类型，对于CISC感兴趣的朋友可以自行查阅相关的手册。

1.2 ARM指令集

执行状态

在前面的文章中讨论CPU架构的时候，我们了解到ARM CPU架构也是经历逐渐迭代升级的过程，那么最近一次的重要变化就是从ARMv7的32位总线升级到了ARMv8系列A35之后的64位总线，考虑到向前软件版本兼容的性，ARMv8的64位版本同时也支持32位总线架构需求，那么CPU工作在不同总线宽度的模式下，执行的状态肯定是不一致的，下面引用一段ARM手册中的描述：

The ARMv8 architecture defines two Execution States, AArch64 and AArch32. Each state is used to describe execution using 64-bit wide general-purpose registers or 32-bit wide general-purpose registers, respectively. While ARMv8 AArch32 retains the ARMv7 definitions of privilege, in AArch64, privilege level is determined by the Exception level. Therefore, execution at ELn corresponds to privilege PLn.
When in AArch64 state, the processor executes the A64 instruction set. When in AArch32 state, the processor can execute either the A32 (called ARM in earlier versions of the architecture) or the T32 (Thumb) instruction set.

ARMv8处理器⽀持两种执⾏状态：AArch64状态和AArch32状态。AArch64状态是ARMv8新增的64位执⾏状态，⽽AArch32是为了兼容ARMv7体系结构的32位执⾏状态。当处理器运⾏在AArch64状态下时，运⾏A64指令集；⽽当运⾏在AArch32状态下时，可以运⾏A32指令集或者T32指令集。执行状态之间是可以切换的，具体切换规则如图1-3所示。

图1-3 AArch64 vs AArch32

执行模式

从指令集合的角度，ARM体系定义了两种状态，不同的执行状态下运行的指令集是不一样的。而从处理器的运行模式角度看去，指令工作的环境也不一样，如图1-4 1-5所示。

图1-4 AArch32 PE Modes

图1-5 AArch64 & AArch32 PE Modes

指令集执行模式的切换规则，这里我们直接引用ARM官方的说明：

Movement between Exception levels follows these rules:
• Moves to a higher Exception level, such as from EL0 to EL1, indicate increased software execution privilege.
• An exception cannot be taken to a lower Exception level.
• There is no exception handling at level EL0, exceptions must be handled at a higher Exception level.
• An exception causes a change of program flow. Execution of an exception handler starts, at an Exception level higher than EL0, from a defined vector that relates to the exception taken. Exceptions include:
— Interrupts such as IRQ and FIQ.
— Memory system aborts.
— Undefined instructions.
— System calls. These permit unprivileged software to make a system call to an operating system.
— Secure monitor or hypervisor traps.
• Ending exception handling and returning to the previous Exception level is performed by executing the ERET instruction.
• Returning from an exception can stay at the same Exception level or enter a lower Exception level. It cannot move to a higher Exception level.
• The security state does change with a change of Exception level, except when retuning from EL3 to a Non-secure state.

这一个小结其实可以归结为一句话，指令的执行是有权限控制的。在AArch64的执行状态下，这个权限的度量就是Exception Level，EL模型对于虚拟化来说非常重要，后面会有专门文章来探讨ARM的异常相关课题，而本文我们会集中讨论AArch64状态下的指令。到这里我们已经明确了在一个ARM-core上干活的指令集有哪些，指令集干活时该遵守哪些规矩也明确了。

功能分类

指令集在功能层面大概会分为这么几类：
(1) 数据处理(整型、浮点型、位、数据size转换、数据格式转换、向量、矩阵等)。
(2) 访问操作(寄存器、cache、主存、不同size数据、不同类型数据等)。
(3) 分支管理(代码的执行流管理，判断、比较、跳转、循环、条件选择)
(4) 函数调用(面向过程的结构化编码)
(5) 系统调用(SVC、HVC、SMC)
主要这5个方面，手册中都写得非常详细，使用的时候自行查阅就可以，这里不展开讨论。

指令格式

不同版本的ARM体系下，指令集也有所区别，下面引用一段ARM手册中叙述：

Each version of the Arm architecture has its own Arm Architecture Reference Manual, which can be found on the Arm Developer website. Every Arm ARM provides a detailed description of each instruction, including:
• Encoding - the representation of the instruction in memory.
• Arguments - inputs to the instruction.
• Pseudocode - what the instruction does, as expressed in Arm pseudocode language.
• Restrictions - when the instruction cannot be used, or the exceptions it can trigger.
The instruction descriptions for A64 are also available in XML and HTML.

The A64 instruction set is used when executing in the AArch64 Execution state. It is a fixed-length 32-bit instruction set. The 64 in the name refers to the use of this instruction by the AArch64 Execution state. It does not refer to the size of the instructions in memory.

通过上面的描述，我们可以看出AArch64状态下的指令都是32位固定长度的，那么一个指令到底长个啥样子，这么我们举一个ADD的例子，如图1-6所示：

图1-6 ADD (extended register) 编码格式

根据手册的规定，我们解读如下：
(1) sf = 1 表示要做的是64位的寄存器加法
(2) Rm、Rd、Rn 对应着三个寄存器，如ADD X1, X8, X9, 那么此时Rd = 0b00001，Rn = 0b01000，Rm = 0b01001
(3) imm3 代表校验寄存器合法性，超过0x101则无效，AArch64共有32个通用寄存器，5位宽度足以表达，超过就是非法的。
(4) option 代表符号为扩展规则，例如0b000代表“UXTB” 。这些扩展规则可以将一个字节无符号或者有符号数地扩展到16位、32位、64位。

当然，ARM体系下围绕着汇编的指令和编程还涉及到很重要的一个方面那就是关于寄存器的使用以及围绕寄存器的使用而做的编码规定PCS(Procedure Call Standard)，这个后面也会有专门章节详细描述，这里不再赘述。

2.指令集与虚拟化

我们前面介绍虚拟化概论的时候提到捕获-陷入机制，Hypervisor去捕获，GuestOS陷入是实现虚拟化基础的关键点。那么问题来了，Hypervisor到底是如何知道啥时候去捕获GuestOS的操作呢？肯定要有一个角色去通知它，这个角色就是CPU，CPU在执行GuestOS的指令时，要能够发现这个指令对系统是“危险”的，这个危险是带引号的，更合适的表达应该是“敏感”的操作比较好。而这些敏感的操作是需要芯片架构提前设计好的，关于这个设计的理论，计算机科学家早在好多年前就提出来了。本节，我们就来探索一下“敏感指令”这个概念，以及它与虚拟化技术之间的关系。

Ssensitive instructions(敏感指令)

查阅现在的文献最早提出敏感指令这个概念是两位美国的学者在很早的一片论文中的“Instruction Behavior”章节中描述的，下面引用一些文献中的节选片段如下:

We classify instructions on the basis of their behavior as a function of the state S of the machine. Which groups an instruction falls into
will determine whether the real machine is virtualizable.
Another important group of instructions will be called sensitive instructions [4]. The members of this group will have a major bearing on the virtualizability of a particular machine. We define two types of sensitive instructions.
That is, an instruction is control sensitive if it attempts to change the amount of (memory) resources available, or affects the processor mode without going through the memory trap sequence. The examples given of privileged instructions are also control sensitive.
Example of behavior sensitive instructions:
Location sensitive–load physical address (IBM 360/67 ERA).
Mode sensitive–move from previous instruction space (DeC PDP-11/45 MVPI). (This instruction forms its effective address from information that depends on the current mode.)
By definition, we shall say that an instruction i is sensitive if it is either control sensitive or behavior sensitive. If i is not sensitive, then it is innocuous.

文献的核心思想就是描述满足什么的要求才能够构建现代的支持虚拟化技术的计算机系统，并且对VMM的分类和特性以及指令的分类以及要求也做了详细的描述。其中对敏感指令也做了具体的要求和分类: 控制敏感和行为敏感 。
对控制敏感的指令是指可以控制硬件配置的指令，例如用于更改执行权限级别，禁用/开启中断或配置虚拟内存设置的指令。 行为敏感指令是根据其执行的CPU模式以及整个系统的配置状态而执行不同的指令。 例如，启用或禁用虚拟内存的指令对控制敏感，而读取当前的CPU模式则对行为敏感。特权指令是那些只能从特权模式执行的指令，最重要的是，在非特权模式下执行时，它们会陷入特权模式。显然，如果用于该计算机系统的敏感指令集是特权指令集的子集，则可以构造虚拟机监视器VMM，也就是说可以100%的满足虚拟化系统的构建。因为此时，GuestOS所有的“危险”操作行为都能够被CPU截获并转发给Hypervisor进行处理。
支持虚拟化计算机的CPU也是one by one的pipelin执⾏指令，包括GuestOS的指令。只不过在虚拟化环境中需要先模拟出CPU，然后才能执⾏guest OS的指令，这⾥模拟的CPU即为vCPU，而vCPU主要是负责为执行GuestOS指令提供一个可供VMM管理的上下文(context)，一般的虚拟化架构下vCPU都会被实现为一个特殊的线程，它可以被调度到任意物理CPU-Core上执⾏。CPU包含各种寄存器⽤于存储数据、指令、状态等，当 CPU 执⾏敏感指令(如 I/O、操作某些寄存器)时，将会引起 VM exit，陷⼊到Hypervisor中，由Hypervisor代为执⾏指令，此时会将GuestOS模式下物理CPU的状态(上下文)保存到vCPU结构的一个特殊字段中，当Hypervisor模拟指令完成后，将触发VM entry，此时从vCPU结构的一个特殊字段中的载⼊Guest OS 退出时的上下文重现装载到物理CPU继续执行。
例如，在不支持中断嵌套的GuestOS上的kernel内部需要响应中断，那么GuestOS的中断处理流程的上半部程序一般需要先关闭系统中断(CPU level 或者是中断控制器 level)，但是此时GuestOS的行为就是一个“危险”的敏感操作，那么此时CPU就会截获这个异常的操作，先挂起GuestOS所在的vCPU线程，并把它的敏感行为记录下来并转发给Hypervisor进行模拟处理，Hypervisor收到后则会配置中断控制器或者是虚拟中断控制器停止向这个vCPU发送中断消息，然后通知CPU把控制全交给GuestOS继续执行(重新调度vCPU线程)，那么等到GuestOS的中断上半部程序执行完成，会调用相关接口打开vCPU的中断，那么这同样是一个敏感行为，同样会被CPU截获并执行上述相反的动作，但是流程是一样。
可以说敏感指令的设计是实现虚拟化技术的基础，但是如文献中苛刻的要求所有的敏感指令全部特权化也不是100%的必要条件，x86和ARM都有敏感指令的漏洞，通过软件定制化开发和扩展虚拟化支持技术一样能够实现虚拟化在特定CPU架构上实现。

AArch64中的敏感指令

AArch64敏感指令是指在ARMv8架构的64位执行状态(AArch64)下，具有特定安全或敏感性的指令。这些指令可能涉及到系统控制、内存访问、加密解密、安全认证等敏感操作。然而，需要注意的是，ARM并没有明确标出哪些指令是“敏感”的，因为这取决于具体的应用场景和安全需求。在某些应用中，某些指令可能因为涉及到敏感数据或系统资源而被视为敏感指令。
以下是一些在AArch64架构中可能被认为是敏感指令的示例：

系统控制指令：这些指令用于控制系统级功能，如电源管理、中断处理、缓存控制等。由于这些指令能够影响系统的整体行为，因此它们可能被视为敏感指令。
内存访问指令：这些指令用于访问系统内存，包括加载和存储指令。在某些应用中，对特定内存区域的访问可能受到限制或监控，因此这些指令可能被视为敏感指令。
加密解密指令：如果处理器支持硬件加密解密功能，那么这些指令将用于执行加密解密操作。由于加密解密涉及到敏感数据的保护，因此这些指令可能被视为敏感指令。
安全认证指令：这些指令用于执行安全认证操作，如身份验证、密钥交换等。这些操作对于保护系统的安全性至关重要，因此相关的指令可能被视为敏感指令。
需要注意的是，这些示例并不是绝对的敏感指令列表，而是根据一般的安全需求和应用场景进行推断的。在实际应用中，哪些指令被视为敏感指令可能因具体的安全策略和需求而有所不同。

看一段手册中对于HVC指令的描述：

HVC
Hypervisor Call causes an exception to EL2. Software executing at EL1 can use this instruction to call the hypervisor to request a service.
The HVC instruction is UNDEFINED :
• When EL3 is implemented and SCR_EL3.HCE is set to 0.
• When EL3 is not implemented and HCR_EL2.HCD is set to 1.
• When EL2 is not implemented.
• At EL1 if EL2 is not enabled in the current Security state.
• At EL0.
On executing an HVC instruction, the PE records the exception as a Hypervisor Call exception in ESR_ELx, using the EC value 0x16, and the value of
the immediate argument.

HVC就是AArch64中的一条显式的敏感指令，它清楚的告诉处理器和码农，调用HVC之后会引起EL的切换，发生异常了，赶紧处理吧。手册中对能够引发异常的指令基本都做了描述，如图1-7所示。

图1-7 AArch64 ISA Exception

ARM非敏感指令
除了会引起ARM异常状态的ARM指令之外的所有指令都是不敏感指令，但是也有特例，下面我们引用一段ARM手册中对“LDADD, LDADDA, LDADDAL, LDADDL”等指令的描述：

If PSTATE.DIT is 1, the timing of this instruction is insensitive to the value of the data being loaded or stored.

从另外一个方面说明ARM中敏感指令需要根据当前的CPU的状态可配置的，这里面我们不展开讨论，同样需要的时候查询手册即可，如图1-8所示。

图1-8 ARM非敏感指令

我们在做Hypervisor的开发的时候就要利用ISA提供的机制去设计和编码，同样在做GuestOS的开发的时候为了提高性能也要尽量优化代码尽量避免去调用敏感指令从而让GuestOS的执行更加的顺畅。

结语

本文我们从一段demo的c语言代码开始，逐步的展开介绍了ISA相关的一些基础知识，最后也引出了关于指令集和虚拟化技术之间的逻辑关系。当然关于指令和指令集的内容还有很多值得探讨的，例如指令的寻址方式，指令的构成等等，而我们本篇主要还是聚焦于虚拟化相关内容，关于指令后续会专门写ARM体系的文章进行详细的阐述，on the way。
ISA对于很多上层应用的开发者还是很陌生的。以linux系统为例，即便是BSP的开发者也很少涉猎汇编语言的开发，而相关体系的代码也是极少的几个大牛在各自维护，但是还是建议大家花些时间研究一下其中的奥秘。现在如火如荼的RISC-v，也有很多人在研究，它非常重要，因为现有系统ISA基本都要授权，而Risc-v也许是可以突破未来被封锁的一个关键的通道。做技术的大牛们请你们继续努力，民族的IC大业靠你们扛起大旗啊。
最后说一句学习ISA也是要多编程，写写汇编的代码跑一跑，不知不觉中终会有收获。每个人守护的那一棵小树苗，只要尽心呵护，早晚都会长成参天大树。

更多精彩内容，请关注公众号

Reference

[00] <80-ARM-ARCH-OVW-wx0003_搞懂ARM处理器架构.pdf>
[01] <80-ARM-ARCH-HK0001_一文搞懂CPU工作原理.pdf>
[02] <80-ARM-ARCH-HK0002_一文搞懂Cortex-A77_ARMv8架构工作原理.pdf>
[03] <80-VIRT-OVW-zh0001_虚拟化基本原理.pdf>
[04] <80-ARM-ARCH-OVW-cs0002_ARM64体系结构编程与实践-基础知识.pdf>
[05] <A-Profile/DEN0013D_cortex_a_series_PG.pdf>
[06] <DEN0024A_v8_architecture_PG.pdf>
[07] <learn_the_architecture_-_a64_instruction_set_architecture_guide_102374_0102_01_en.pdf>
[08] <ISA_A64_xml_A_profile-2024-03.pdf>
[09] <325462-sdm-vol-1-2abcd-3abcd-4.pdf>
[10] <80-V-OVW-T0001_Formal_Requirements_for_Virtualizable_Third_Generation_Architectures.pdf>
[11] <SysReg_xml_A_profile-2024-03.pdf>

Glossary

SSE - Simple Sequential Execution
TLB - Translation lookaside buffer(地址变换高速缓存)
A-profile - Application-profile (A-profile)
R-profile - Real-time profile (R-profile)
SVE - Scalable Vector Extension (SVE)
M-profile - Microcontroller-profile (M-profile)
RME - Realm Management Extension 领域管理扩展
SME - Scalable Matrix Extension
MPAM - Memory System Resource Partitioning and Monitoring(MPAM)
ISA - Instruction Set Architecture 指令集架构
RAS - Reliability, Availability, and Serviceability (RAS)
TRM - Technical Reference Manual
SysReg - System Registers
PG - Programmer’s Guide
SCMI - System Control and Management Interface (SCMI)
ACPI - Advanced Configuration and Power Interface (ACPI)
PSCI - Power State Coordination Interface (PSCI)
UEFI - Unified Extensible Firmware Interface (UEFI)
UART - Universal Asynchronous Receiver/Transmitter
SPI - Shared Peripheral Interrupt
PPI - Private Peripheral Interrupt
SGI - Software Generated Interrupts
MPAM - Memory System Resource Partitioning and Monitoring
LPI - Locality-specific Peripheral Interrupt (LPI)
PE - Processing Element
MSI - message-signaled interrupts (MSI)
IAR - Interrupt Acknowledge Registers
EOIR - End of Interrupt Registers
IRM - Interrupt Routing Mode
ITS - Interrupt Translation Service
ITT - Interrupt Translation Tables
DCVS - Dynamic clock and voltage scaling
soc - System-on-a-Chip
AMBA - Advanced Microcontroller Bus Architecture
AMBA - Advanced Microcontroller Bus Architecture 高级处理器总线架构
AHB - Advanced High-performance Bus 高级高性能总线
ASB - Advanced System Bus 高级系统总线
APB - Advanced Peripheral Bus 高级外围总线
AXI - Advanced eXtensible Interface 高级可拓展接口
PAS - physical address spaces
ASIDs - Address Space Identifiers
PCSA - power control system architecture
EAS - energy aware scheduling
IPA - intrlligent power allocation
ATF - ARM Trusted Firmware
SCP - system control processor
PCF - power control framework
PPU - power policy unit
LPI - low power interface
PCSM - power control state machine
AP - Application Processors
SCP - System Control Processor (SCP)
SMC - Secure Monitor Call (SMC)
HVC - Hypervisor Call (HVC)
OPP - Operating Performance Point (OPP)
DVFS - Dynamic Voltage and Frequency Scaling (DVFS)
DCVS - Dynamic Clock and Voltage Scaling (DCVS)
AMU - Arm Activity Monitors Extension (AMU)
EAS - Energy Aware Scheduling
IPA - Intelligent Power Allocation
AP - Application Processor (AP)
SIMD - Single Instruction Multiple Data(SIMD)
VBAR - Vector Base Address Register
SCTLR - System Control Register
ELR - Exception Link Register
ESR - Exception Syndrome Register
FAR - Fault Address Register
HCR - Hypervisor Configuration Register
SCR - Secure Configuration Register
SCTLR - System Control Register
SPSR - Saved Program Status Register
UART - Universal Asynchronous Receiver/Transmitter
ALU - Arithmetical Logical Unit
NMI - non-maskable interrupts
BSA - Base System Architecture
SBSA - Server Base System Architecture
BBR - Base Boot Requirements
TBSA - Trusted Base System Architecture
AMBA - Advanced Microcontroller Bus Architecture
TRM - Technical Reference Manual
MMU - Memory Management Unit
DSU - DynamIQ Shared Unit
BPU - Branch Predictor Unit
INTID - Interrupt ID
SBSA - Server Base System Architecture
ESR - Exception Syndrome Register
FAR - Fault Address Register
ELR - Exception Link Register
VBAR - Vector Base Address Registers
SMP - Symmetric Multi-Processing
AMP - Asymmetric Multi-processing
HMP - Heterogeneous multi-processing 异构多处理
PSTATE - Process state, PSTATE
PCS - Procedure Call Standard