PRTOS Hypervisor — LoongArch64 平台适配技术方案

本次适配为 PRTOS 分离内核 架构 Type-1（裸金属）Hypervisor新增了 LoongArch64 平台支持。LoongArch64 是龙芯自主指令集架构，采用 64 位 RISC 设计，具备 LVZ (LoongArch Virtualization) 硬件虚拟化扩展。

适配实现了 双模式虚拟化:

在 setup.c 的 setup_arch_common() 中通过 CPUCFG[2] 第 10 位 (LVZP) 检测 LVZ 支持:

void detect_lvz(void) {
    prtos_u32_t cfg2;
    asm volatile("cpucfg %0, %1" : "=r"(cfg2) : "r"(2));
    prtos_lvz_available = (cfg2 >> 10) & 0x1;
}

LVZ 初始化 (init_lvz()) 配置以下 Guest 管理 CSR:

Guest 进入 (JMP_PARTITION_LVZ 宏, asm.h):

1. 设置 CSR.ERA = Guest 入口地址
2. 设置 CSR.PRMD = 0x4 (PPLV=0, PIE=1)
3. 配置 GSTAT.GID 和 PVM=1 (进入 Guest 模式)
4. 设置 GTLBC.TGID = GID (TLB 条目关联到此 Guest)
5. 写 LVZ 标志到 CSR.SAVE5
6. 保存 Host SP 到 CSR.SAVE0
7. 执行 ertn 进入 Guest 模式

Guest 退出 (entry.S — _trap_from_lvz_guest):

当 Guest 执行特权操作或发生异常时，LVZ 硬件触发 VM Exit:

1. 检查 GSTAT.PVM == 1 确认是 LVZ Guest 退出
2. 清除 GSTAT.PVM (退出 Guest 模式)
3. 清除 GTLBC.TGID = 0 (后续 TLB 操作不影响 Guest 条目)
4. 设置 SAVE5 = 1 (标记 LVZ 活跃)
5. 切换到 Host 栈 (从 SAVE0 恢复)
6. 保存 Guest 寄存器上下文
7. 进入 C 陷入处理器 loongarch64_trap_handler()

LVZ Guest 执行特权指令时产生 GSPR 异常 (ecode=0x1A)，而非 IPE。处理流程:

1. 从 CSR.BADI 读取陷入指令 (非从 ERA 地址读取，避免 TLB 问题)
2. 解码指令类型:
   • CPUCFG: 直通硬件值，屏蔽 PTW/LSX/LASX 特性位
   • IOCSR 读写: 直通到硬件 (用于 EIOINTC 中断控制器访问)
   • IDLE: 跳过 (推进 PC)
   • CSR 操作: 调用 emulate_privileged_insn() 统一处理

这是整个适配中最核心的函数 (~800 行), 实现了完整的 LoongArch64 CSR 陷入-模拟机制:

CSR 指令解码 (opcode 0x04):

• CSRRD (rj==0): rd = guest_csr_read(ka, csr_num)
• CSRWR (rj==1): 交换 — old = read; write(new); rd = old
• CSRXCHG (rj≠0,1): 掩码交换 — new = (old & ~mask) | (val & mask)

软件 CSR 影子寄存器: 在 struct kthread_arch 中维护了超过 60 个 Guest CSR 的影子副本:

关键设计决策:

• EUEN 直通: Guest 写 EUEN 时直接操作硬件，实现 FP/LASX 上下文的惰性管理
• ECFG/CRMD 写触发中断检查: 每次写入后调用 check_guest_pending_irqs()，实现延迟虚拟中断的及时投递
• ERA 先行推进: 在处理虚拟中断投递前推进 ERA，确保中断处理器保存正确的返回地址

translate_guest_tlbelo(): Guest TLB 条目地址翻译的核心:

1. 从 Guest TLBELO 提取 GPA (Guest Physical Address)
2. 以 1MB 为粒度在 tlb_refill_table[] 中查找对应的 HPA
3. 构造 Host TLBELO: HPA + 强制 PLV=3 访问权限
4. 若页面不在分区允许的内存区域内，返回 0 (拒绝访问)

完整模拟了 LoongArch64 的硬件页表遍历器:

• LDDIR: 从 BADV 中提取目录索引 (使用 PWCL/PWCH 配置的 Dir1-4 base/width)，通过 DMW1 直接访问 Guest 物理内存加载页目录项
• LDPTE: 加载 PTE 到 guest_tlbrelo0/1，设置 TLBREHI.PS

if (guest_in_tlb_refill):
    guest_crmd ← guest_tlbrprmd  # 从 TLB Refill 返回
else:
    guest_crmd ← guest_prmd      # 从普通异常返回

恢复后触发 check_guest_pending_irqs() 处理挂起虚拟中断。

deliver_virtual_irq() 模拟硬件异常入口序列:

1. 保存 guest_crmd → guest_prmd (PPLV + PIE)
2. 保存当前 ERA → guest_era
3. 清除 guest_crmd.IE，设置 PLV=0
4. 计算向量化入口: VS>0 时 entry = eentry + (64 + hwirq) * vec_size — 匹配 Linux 的 EXCCODE_INT_START=64 约定
5. 设置 regs->era 为计算出的向量地址

check_guest_pending_irqs(): 当 guest_crmd.IE 开启且 guest_estat & guest_ecfg & 0x1FFF 非零时，调用 deliver_virtual_irq()。

指令: syscall 0 (LoongArch64 同步异常指令)

调用约定:

Hypervisor 在 traps.c 中处理 SYS (ecode=0xB) 异常:

1. 检查 $a7 == 0 确认是 PRTOS hypercall
2. 从 $a0 获取 hypercall 编号
3. 分发到对应处理函数 (与其他架构共享 hypercall 表)

半虚拟化 Guest 运行在 PLV3，执行特权指令时触发 IPE 异常 (ecode=0xE)。处理流程与 GSPR 相同:

1. 从 CSR.BADI 读取陷入指令
2. 解码并模拟 CSR 读写、TLB 操作、IOCSR 访问等
3. 推进 Guest ERA
4. 返回 Guest 继续执行

JMP_PARTITION 宏 (para-virt 路径):

1. 设置 ERA = entry, PRMD = 0x7 (PPLV=3, PIE=1)
2. 保存 Host SP 到 CSR.SAVE0
3. $a0 = PCT (Partition Control Table) 物理地址
4. ertn 进入 PLV3

半虚拟化中断投递 (fix_stack() in irqs.c):

1. 保存 era, crmd, $a0, $a7 到 PCT arch 字段
2. 设置 irq_vector (高位标记: vector | 0x80000000)
3. 重定向 regs->era 到 pct->arch.trap_entry
4. Guest 中断处理完成后通过 IRET hypercall (nr=44) 恢复: 从 PCT 恢复 era, crmd, $a0, $a7

完全定制的 FreeRTOS 端口 (freertos_para_virt_loongarch64/):

硬件虚拟化模式下的 FreeRTOS 使用 完全未修改的原生代码:

LoongArch64 平台的内存模型基于 DMW，这是与 ARM/RISC-V/x86 架构最显著的区别:

设计影响:

• vm_map_page() 是 空操作 — DMW 已覆盖全部物理地址空间
• read_by_pass_mmu_*()/write_by_pass_mmu_*() 是简单的指针解引用
• Hypervisor 不需要页表层次结构
• 内存访问公式: VA_cached = PA | 0x9000_0000_0000_0000, VA_uncached = PA | 0x8000_0000_0000_0000

prtos_u64_t tlb_refill_table[CONFIG_NO_CPUS][4096];  // 每 CPU 4096 条目 × 1MB = 4GB 覆盖

每个条目是完整的 TLBELO 值 (64-bit) 或 0 (不可访问)。此表实现了 1MB 粒度的分区间内存隔离。

表的物理地址存储在 CSR.SAVE4 中，供 TLB Refill 处理器在 DA 模式下直接访问。

每次分区切入前调用，配置当前分区的内存视图:

1. 清零表 — 所有页面对 PLV3 不可访问
2. 映射 Hypervisor — 前 2MB 从 CONFIG_PRTOS_LOAD_ADDR 起，只读 (V=1, D=0, PLV3, CC, G)
3. 映射分区内存区域 — 遍历 XML 配置的 physical_memory_areas:
   • 普通: V|D|PLV3|CC|G
   • 只读: V|PLV3|CC|G (无 D 位)
   • 非缓存: V|D|PLV3|G (MAT=SUC)
4. 映射 PCT 页 — 只读
5. 写入 CSR.SAVE4 — 更新 refill 表物理地址
6. 全量 TLB 刷新 — invtlb 0x0

运行在 DA 模式 (VA=PA, PLV0)，仅使用 $t0/$t1:

地址分类:

表查找算法:

1. 计算 1MB 页面索引 (GPA >> 20)
2. 偶数页: 加载 TLBRELO0
3. 奇数页: 加载 TLBRELO1
4. 设置 TLBREHI = 2MB 对齐基址 | PS=20 (1MB)
5. 执行 tlbfill

拒绝路径: 未映射地址填充 V=0, G=1, PS=14 (16KB) 条目。选择 PS=14 是因为匹配 Guest 内核的 STLBPS 配置，避免 Guest 后续 TLBFILL 时产生 Multi-hit 异常。

对于 PIL/PIS/PIF (ecode 1-3):

1. DMW 地址: 提取 GPA，查 refill 表，填充 1MB TLB 条目
2. 直接 GPA (< 4GB): 同上
3. Guest 虚拟地址: 通过 deliver_guest_exception() 向 Guest 投递页错误异常

对于 PME (ecode 4, 页修改异常): 临时设置 D=1 允许写入，下次 TLB 刷新时恢复。

硬件基础: LoongArch64 Stable Counter (100 MHz on QEMU virt)

• get_time hypercall (nr=9): 读取 Stable Counter
• set_timer hypercall (nr=10): 设置定时器中断间隔

Guest 直接读写 CSR.TCFG/TVAL/TICLR，Hypervisor 模拟:

LVZ Guest 定时器: 通过 IOCSR syscall (PRTOS_EXT_TIMER) 直接编程硬件 TCFG。

LoongArch64 独有的 IOCSR 机制用于访问片上设备 (EIOINTC, IPI, PCH-PIC 等)。

对于 para-virt IPE 和 LVZ GSPR 陷入，IOCSR 读写指令 直通到硬件:

handle_iocsr_passthrough(insn, regs):
    width = decode(insn[11:10])  // byte/half/word/dword
    addr  = regs[rj]
    iocsrrd/iocsrwr(width, addr, &data)

写操作后调用 manage_hwi_state() 检查 EIOINTC ISR 是否被清除。

为 LVZ hw-virt Guest 提供类似 RISC-V SBI 的系统调用接口 (prtos_iocsr.c):

EIOINTC (Extended I/O Interrupt Controller) 是 LoongArch64 的高级中断路由器。

HWI (硬件中断) 处理流程:

1. 硬件中断触发 ESTAT.IS[2:9]
2. Hypervisor 陷入处理器:
   • 屏蔽 ECFG 中对应位 (防止重入)
   • 注入 到 guest_estat 对应位
   • 记录到 karch.hwi_injected 位图
3. Guest 处理中断 (通过 IOCSR 清除 EIOINTC ISR)
4. manage_hwi_state() 检测 ISR 已清除后:
   • 重新启用 ECFG 对应位
   • 清除 guest_estat 和 hwi_injected 对应位

双分区 Virtio 架构 (virtio_linux_demo_2p_loongarch64/):

┌────────────────────────────────────────────────────┐
│  PRTOS Hypervisor (32MB)                            │
├─────────────────────┬──────────────────────────────┤
│ System Partition     │ Guest Partition               │
│ (hw-virt, 2 vCPU)  │ (hw-virt, 2 vCPU)            │
│                     │                               │
│ Linux + Backend     │ Linux + Frontend              │
│ Daemon              │ Driver                        │
│                     │                               │
│ GPA: 0x80000000     │ GPA: 0xA0000000              │
│ 512MB RAM           │ 512MB RAM                    │
└────────┬────────────┴──────────┬───────────────────┘
         │    Shared Memory      │
         └───────────────────────┘
              5 Regions @ 0xC0000000

共享内存区域:

Backend 守护进程在 System Partition 的 Linux 用户空间运行: 通过 /dev/mem + mmap() 映射共享内存区域，使用 PRTOS Hypervisor 接口 (prtos_hv_raise_partition_ipvi()) 通知 Guest。

LoongArch64 的 SMP 启动基于 IOCSR 邮箱:

1. BSP 调用 write_remote_mailbox(cpu, _secondary_start_addr):
   • 将 _secondary_start 物理地址写入目标 CPU 的 IOCSR CORE_BUF_20 (地址 0x1020)
   • 通过 IOCSR_MAIL_SEND (0x1048) 发送
2. 通过 IOCSR_IPI_SEND (0x1040) 发送 IPI 唤醒目标 CPU
3. 目标 CPU 从 QEMU slave_boot_code 轮询循环中醒来
4. _secondary_start 中执行: 配置 DMW → DA→PG 切换 → 调用 init_secondary_cpu()

prtos_hsm_vcpu_start(target_vcpuid, start_addr, opaque):

1. 验证目标 vCPU 在分区 num_of_vcpus 范围内
2. 存储 hsm_entry 和 hsm_opaque 到目标 kthread 的 karch
3. 调用 setup_kstack() 设置初始栈帧
4. 设置 KTHREAD_READY_F，清除 KTHREAD_HALTED_F

QEMU virt firmware
    ↓
RSW (Resident SW) — DA 模式, PA
    ├── CPU 0: rsw_main() → 解包 container.bin → 跳转到 PRTOS 入口
    └── CPU 1-3: 轮询邮箱 (PA 0x100 + cpuid*8)
        ↓
PRTOS Hypervisor — start.S
    ├── BSS 清零 (PA)
    ├── DMW0 临时跳板 (VSEG=0x0, 覆盖当前 PC)
    ├── DMW1 最终窗口 (VSEG=0x9, CC, PLV0+PLV3)
    ├── DA→PG 模式切换
    ├── 虚拟空间跳转 (jr $s1 → _virtual_start)
    ├── DMW0 重配置 (VSEG=0x8, SUC, PLV0+PLV3)
    ├── 异常入口设置 (EENTRY, TLBRENTRY)
    ├── ECFG 配置 (TI, IPI, HWI0-7)
    └── setup_kernel(cpu_id=0, idle_kthread)
        ├── 通用初始化 (调度器, 内存, 分区)
        ├── 架构初始化 (detect_lvz, init_lvz, timer)
        ├── SMP 启动 (IOCSR 邮箱 → IPI 唤醒)
        │   └── 副 CPU: _secondary_start → DMW → PG → init_secondary_cpu()
        └── 调度器启动 → JMP_PARTITION / JMP_PARTITION_LVZ

这是 LoongArch64 启动中最精妙的部分。由于 DA→PG 切换是单条指令完成的 (写 CRMD)，需要确保切换瞬间的取指不会失败:

1. 配置 DMW0: VSEG=0x0 — 映射当前 DA 模式的地址范围
2. 配置 DMW1: VSEG=0x9 — 最终虚拟地址窗口
3. csrwr CRMD (PG=1, DA=0) — 此刻 PC 仍在低地址，DMW0 保证取指继续
4. jr $s1 — 跳转到 0x9000... 地址空间
5. 重配置 DMW0 为最终值 (VSEG=0x8, SUC)

• 运行在 DA 模式，无 DMW 需求
• CPU 0 执行 rsw_main()，解包 container.bin (PRTOS core + 分区镜像)
• 副 CPU 轮询物理地址 0x100 + cpuid*8 的邮箱

分区引导框架:

1. 从 $a0 获取 PCT 物理地址
2. 通过 syscall 0 (get_vcpuid) 获取 vCPU ID
3. vCPU 0 清零 BSS
4. 每 vCPU 独立栈: sp = _stack + (vcpuid + 1) * STACK_SIZE
5. 调用链: init_libprtos() → init_arch() → setup_irqs() → partition_main()

提供 _PRTOS_HCALL0 ~ _PRTOS_HCALL5 宏，封装 syscall 0 指令。特殊 hypercall:

• IRET (nr=44): 从 PCT 恢复 era, crmd, $a0, $a7
• RAISE_TRAP (nr=45): 向分区注入陷入

linux_4vcpu_1partion_loongarch64/start.S:

1. 写 'V' 到 UART (验证标记)
2. 设置 Linux 启动协议参数: a0=0 (non-EFI), a1=0 (cmdline forced), a2=0 (no EFI table)
3. 跳转到内核入口: _linux_image_start + 0x1622000 (kernel_entry offset)
4. vmlinux.bin 通过 .incbin 嵌入在 2MB 对齐偏移处

Linux 相关测试采用 文件型 chardev 轮询 方案替代 pexpect/PTY:

• QEMU 启动参数: -serial chardev:s0 -chardev file,id=s0,path=...
• 测试循环: 每 5-10 秒 grep 日志文件检查预期模式
• 原因: QEMU LoongArch64 PTY 串口仅显示 RSW 引导消息，NS16550 UART 输出未映射到 PTY

QEMU 配置: qemu-system-loongarch64 -machine virt -cpu max -smp 4 -m 2G

======================================
  Test Report [loongarch64]
======================================
  Total: 32  Pass: 16  Fail: 0  Skip: 16
======================================

16 个 LoongArch64 相关测试全部 PASS，16 个其他架构测试正确 SKIP。

1. DMW PLV3 启用: 需要同时为 PLV0 (Hypervisor) 和 PLV3 (Guest) 启用 DMW，Guest 可使用 0x8000.../0x9000... 内核 VA
2. TLB Refill DA 模式: TLB Refill 处理器运行在 DA 模式 (VA=PA)，需要在物理地址空间维护 refill 表
3. BADI 指令读取: 从 CSR.BADI 读取陷入指令而非 ERA 地址，避免 Guest TLB 上下文中的 TLB Miss
4. V=0 Deny 条目 PS 匹配: 拒绝条目使用 PS=14 (16KB) 匹配 Guest STLBPS，防止 Multi-hit 异常
5. IOCSR 双重角色: 既是设备访问接口 (EIOINTC, IPI)，又是 SMP 启动的邮箱机制
6. DA→PG 跳板: 需要临时 DMW0 (VSEG=0x0) 保证模式切换时的连续取指

用户态和示例代码另外约 40,000 行 (含 FreeRTOS 端口、Linux 示例、Virtio 框架)。