OPTEE 说明

本文档是说明RISC-V架构相关的OPTEE实现，不讲OPTEE的工作原理，OPTEE的工作原理请参考官方文档(http://optee.readthedocs.io/).

我们基于RISC-V实现的OPTEE和ARM基本类似，也分为两个世界：安全世界(TEE)，非安全世界(REE)。
两个世界彼此隔离，包括代码执行隔离，中断隔离。目前单核多核都已支持，当CPU在TEE执行时，不能被非安全中断打断；CPU在REE执行时，可以被安全中断打断。另外_wg后缀的分支已支持CPU硬件安全状态位，世界切换时，状态位会改变。目前TEE系统需要M模式下PLIC中断控制器pending可写，需要支持shartid csr。

启动过程

optee-os 会被freeloader从flash介质加载到内存，由opensbi来初始化optee，初始化完成后opensbi继续启动uboot，直到linux启动完成。

运行过程

RISC-V OPTEE系统的运行架构如下图：

由opensbi 负责安全世界和非安全世界上下文的管理，opensbi实现和ARM ATF类似功能。与ARM不同的是当前cpu的安全状态由软件负责管理，
系统从上电运行，不同阶段上下文的切换如下:

• optee os初始化阶段，opensbi在平台初始化阶段，通过mret进入optee os，optee os完成初始化后ecall返回opensbi，此时opensbi保存optee os的cpu上下文，即保存安全世界上下文。
• ree os 运行阶段，当需要optee服务时，ree os通过ecall发出optee请求，opensbi收到请求后，保存当前cpu状态到非安全状态上下文，然后恢复安全状态上下文及转发请求给optee os处理，optee os处理完成后ecall返回到opensbi，opensbi 保存当前cpu状态到安全状态上下文，然后保存optee返回值，恢复非安全状态上下文到ree os继续执行。

nuclei sdk

目录结构

1
2
3
4
5
6
7
8
9
10
11

nuclei-sdk
├── Build  #build 生成目录
├── Components  # 空目录
├── NMSIS       # dsp nn的静态库和头文件
├── OS          # FreeRTOS RTThread ucosii 头文件及源码目录
├── SoC         # demosoc gd32vf103 bsp 头文件及源码目录
├── application # baremental FreeRTOS RTThread ucosii 下跑的app 源码
├── doc         # 文档
├── logs        # 测试框架生成目录
├── test        # riscv 指令集 中断 fpu pmp timer 等相关测试项, 在baremental下的测试
└── tools       # 测试框架脚本

编译baremental app

例子

1

make PROGRAM=application/baremetal/helloworld SOC=demosoc BOARD=nuclei_fpga_eval all

运行baremental app

例子

1

nuclei_qemu/bin/qemu-system-riscv64  -M nuclei_n -cpu nuclei-ux600 -nodefaults -nographic -serial stdio -kernel application/baremetal/helloworld/helloworld.elf

riscv isa 测试框架

test_page

测试 2-stage translation 页表的 PTE的集合
vs 为 vs-stage translation 的pte
h 为 g-stage translation 的pte

1
2
3
4
5
6
7

struct {
    uint64_t vs;
    uint64_t h;
} test_page_perm_table [] = {
     # index    -----------    vs  ---------------------- h ------#
	[VSRWX_GRWX]      =   {PTE_V | PTE_RWX,         PTE_V | PTE_RWX},
}

页表属性按照PTE的 7:0 位设置相关的bit位

hspt_init

测试框架执行 hspt_init 对2-stage 页表进行初始化
如 tinst_tests 测试项, 该测试集对指令进行测试

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

-+ tinst_tests
 \ -+ hspt_init
    \ -  addr = 0x00000000;
    | -+ for(int i = 0; i < 4; i++)
       \ -  hspt[0][i] = PTE_V | PTE_AD | PTE_RWX | (addr >> 2);  "设置第一级页表 pgd"
       | -  addr += PGSIZE << (2 * 9)   "设置完后, hspt[0][0] -> hspt[0][3] 为 0 0x4000000 0x80000000 0xc0000000 base 地址"
    | -  hspt[0][4] = PTE_V | (((uintptr_t)&hspt[1][0]) >> 2);   "设置PPN 二级页表"
    | -  hspt[1][0] = PTE_V | (((uintptr_t)&hspt[2][0]) >> 2);   "设置 PPN 三级页表"
    | -  addr = TEST_PPAGE_BASE; "0x88000000"
    | -+ for(int i = 0; i < TEST_PAGE_MAX; i++)  "TEST_PAGE_MAX = 512, 一共设置512个PTE"
       \ -+ hspt[2][i] = (addr >> 2) | PTE_AD | test_page_perm_table[i].vs; 
							       "设置PTE 物理地址为 0x88000000 - 0x881ff000 / 间隔 1page"
							       "每个PTE 对应的测试集的权限不同, 取自 test_page_perm_table.vs 权限集"
       | -  addr += PAGE_SIZE;
    | -  CSRW(satp, satp);   "M-mode 或 Hs-mode 下设置satp 为 hspt 基地址即 hspt[0][0]的基址"
 | -  goto_priv(PRIV_HS); "进入hs-mode"
 | -  uintptr_t vaddr_f = hs_page_base(VSI_GI); "VSI_GI=100, vs_page_base 0x100000000 + 100* PGSIZE = 0x100064000"
                            "访问不了, 应该报错"
 | -  TEST_SETUP_EXCEPT(); "初始化 except 数据 为 0"
 | -  value = lb(vaddr_f); "lb load vaddr_f 的数据"
 | -  TEST_ASSERT(excpt.cause == CAUSE_LPF) "测试应该陷入 M-mode handler, 且mcause 应为 13 load page fault"
                                            " 如果未触发异常, 或mcause 不对, case 报错"

大概回顾下页表结构
可见这个是针对sv39 的页表
回顾下 sv39 页表的查表方法

sv39 in RV64:

rvh h-extension 1.0

• sstatus 反映 Supervisor-mode(后面简称 S-mode) 下的cpu 状态, 这里仅以其 SPP(Supervisor previous previlege) 做介绍, 如第一次想从S-mode 执行到 User-mode(下简称U-mode) 下, 需要设置sstatus.SPP=U-mode (0)
• satp (Supervisor Address Translation and Protection (satp) Register), 保存了第一级页表地址
• sepc (Supervisor Exception Program Counter) 保存发生trap/中断 前的 pc 地址, 此处如为第一次执行该用户态应用, 则需要将其设置为用户态的入口地址
• sret (S-mode return), 通俗来讲就是调用sret后, 硬件会设置 pc = spec, 下一条指令从sepc 的位置执行. 除此之外, sret 还会判断 sstatus.SPP 确定下一刻要将cpu 置为哪个特权模式, 此处如为第一次执行用户态应用, 需要将sstatus.SPP 置为 U-mode, 下一刻cpu会切换特权级, 从S-mode 切换到 U-mode.
• scause S-mode 原因寄存器, 在发生异常/中断时, scause 会被硬件修改对应的位, 表明当前进入异常/中断的原因.

虚拟机 os，需要完整的运行环境。
我们考虑一个简单的linux运行需要什么环境

• 1，通用寄存器，传参，sp，pc这些。
• 2，CSR，比如status，cause寄存器这些，配置cpu的运行状态，或者获取cpu的运行状态等。
• 3，内存，需要管理虚拟地址到物理地址的转换。
• 4，trap handler，发生异常或者中断时的处理方法。
• 5，特权等级。

这些东西，通过纯软件也可以做模拟，但是效率和安全性上都会受影响，RVH ISA就是在CPU 硬件层面上给这些虚拟机OS运行环境需要的资源进行了明确的要求和定义。

HS-模式的作用与S-模式相同，但有额外的指令和CSR，2-stage translation, 翻译GVA->HPA, 为guest os 提供内存和mmio的外设地址空间模拟, 常规的S模式操作系统可以在HS模式或VS模式下执行，无需修改。

特权模式

Hypervisor and Virtual Supervisor CSRs

问题1：

boston 使用的 pcie 总线 xinlinx_pcie_root_realize 在调用 pci_bridge_initfn 后， qemu系统中查询 pci_bus 失败

object_resolve_path_type(“”, TYPE_PCI_BUS, NULL)

导致qemu 模拟的iommu 设备无法正常注册

riscv_iommu_sys_realize 函数中不能找到 pci_bus，没有走 riscv_iommu_pci_setup_iommu 函数。

bus->iommu_fn 为 空

问题2：

正常情况下 board 注册完时，会通过 notify 调用 pci_done

最终， 会调用 bus->iommu_fn 函数

riscv_iommu_find_as->riscv_iommu_space->memory_region_init_iommu(as->iova_mr, TYPE_RISCV_IOMMU_MEMORY_REGION)

SPEC

Feature

iommucap register

• S bit: 支持 2-stage 地址翻译
• A bit: 支持 AIA
• MRF: 支持 imsic 的 MRF 模式

iommucapen register
E bit , E=1 时, iommu 开启.

device table walk

• RSID (Requester Source ID) 设备源ID
• RSIDHI
• RSIDLO

device table entry

dtbase 寄存器, 保存 device table 的首地址.

SPEC

Device Table

IOMMU Register Interface

TLB 操作时才会用到下面这些寄存器

IOMMU EntryLo0 and EntryLo1 Register Format

physical frame number (物理地址页号) 35-6 共 30bit.

DMA 重映射

iommu 作用

1. 安全性, 防止恶意访问
   In the absence of an IOMMU, a device driver must program devices with Physical Addresses, which implies that DMA from a device could be used to access any memory, such as privileged memory,and cause malicious or unintended corruptions. This may be caused by hardware bugs, devicedriver bugs, or by malicious software/hardware. 013

在没有IOMMU的情况下，设备驱动程序必须用物理地址对设备进行编程，这意味着来自设备的DMA可以被用来访问任何内存，如特权内存，并造成恶意或意外的损坏。这可能是由硬件错误、设备驱动程序错误或恶意软件/硬件造成的。

2. 使传统的32位外设可以访问超过4G的内存区间, 不再需要软件做 bounce buffers, 提高性能
   Legacy 32-bit devices cannot access the memory above 4 GiB. 013
   The integration of the IOMMU,through its address remapping capability, offers a simple mechanism for the DMA to directly accessany address in the system 013
   Without an IOMMU, the OS must resort to copying data through buffers (also known as bounce buffers) allocated in memory below 4GiB. 013

3. The IOMMU can be useful as it permits to allocate large regions of memory without the need to becontiguous in physical memory 013
   可以使用连续物理内存

中断重映射

MSI 重映射

To handle MSIs from a device controlled by a guest OS, the hypervisor configures an IOMMU toredirect those MSIs to a guest interrupt file in an IMSIC (see Figure 3) or to a memory-residentinterrupt file. The IOMMU is responsible to use the MSI address-translation data structures suppliedby the hypervisor to perform the MSI redirection. Because every interrupt file, real or virtual,occupies a naturally aligned 4-KiB page of address space, the required address translation is from avirtual (guest) page address to a physical page address, 015

hypervisor配置了一个IOMMU，将这些guest 的MSI (GPA) 重定向到IMSIC中的guest interrupt file (HPA)

利用 iommu 重定向能力 使的 guest msi的GPA地址访问直接映射为 HPA的msi的地址访问, 从而让guest 可以直接读写物理msi mmio, 实现中断重映射能力, 中断直通给vcpu.

RERI 规范在 SoC 中增加了 RAS 功能，通过内存映射寄存器接口提供错误报告的标准机制，提供记录检测到的错误(包括其严重性、性质和位置)的功能，并配置了向 RAS 处理程序组件发送错误信号的方法。
RAS 处理程序可以使用此信息来确定合适的恢复操作，这些操作可能包括

• 终止(例如，终止一个进程等)
• 重新启动部分或全部系统等，以便从错误中恢复。
• 此外，该规范应支持软件发起的 RAS 处理程序的错误记录、报告和测试。
• 最后，该规范应提供实现错误处理的最大灵活性，并应与其他标准(如 PCIe、CXL 等)定义的 RAS 框架共存。

错误级别

• CE Corrected error.
• UDE Uncorrected deferred error.
• UUE Uncorrected urgent error.

寄存器

比较重要的 csr:

• Address register (addr_i)

  The addr_i WARL register reports the address associated with the detected error

• Information register (info_i)

  The info_i WARL register provides additional information about the error when status_i.iv is 1

• Status register (status_i)

  The status_i is a read-write WARL register that reports errors detected by the hardware unit
  

• Error bank information (bank_info)

  
  inst_id 字段标识组件的一个包或至少一个芯片内的唯一实例;在整个系统中最好是独一无二的。系统的供应商将 inst_id 定义为组件的唯一标识符。返回值为0表示该字段未实现。
  n_err_recs 字段表示错误记录的数量。

• Control register (control_i)

  control_i 是一个读/写 WARL 寄存器，用于控制错误库中相应错误记录的错误报告。
  The ces, udes, and uues are WARL fields used to enable signaling of CE, UDE, and UUE respectively When they are logged

RAS

RAS（Reliability、Availability and Serviceability），即可靠性、可用性、可维护性。

以下是 RAS 的三个主要目标:

1. 提升系统可运行时间。
   RAS 技术可以提升服务器的可靠性，一般通过测量平均故障时间（MTTF）、年崩溃率（ACR）或年服务率（ASR）来度量。一个可靠的系统将保持运行更长的时间，因此更加可用。

2. 减少非计划停机时间。
   当非计划停机出现时，可以通过测量平均修复时间 MTTR 来度量服务器的可维护性。一个可维护的系统可以快速恢复正常运行。
   硬件和固件协同支撑日志记录，帮助识别和隔离故障，让操作者可以进行预防性或主动性的维护。如果出现停机，可以快速地将系统重新上线，减少维护成本，并减轻停机对企业的后果。

3. 维护数据完整性。
   RAS 技术提供了多种机制来防止数据损坏并纠正出错的数据。当检测到错误数据时，会确保它在可控制的范围内，避免引起更严重的问题。

x86 HPC ras 调研

错误分类

• 可纠正错误 CE
  • 当检测到可纠正错误CE时，对错误位置进行标记，并通过对应模块的RAS技术快速修复错误，用户不会感知到这类错误的发生
• 不可纠正错误 UCE
  • 尝试对故障进行隔离。比如通过隔离内存坏块、总线降频等手段，维持系统的运行。若发生了更为严重的故障，系统直接宕机，这时需要通过带外管理软件HDM恢复或重启系统
• 硬件永久性故障
  • 需要更换新的硬件或者启用备用设备进行修复。通过对部分硬件的热插拔功能，可以支持用户在系统不断电的情况下，进行故障设备的更换，使服务器恢复正常工作。

故障上报