训练营 axvisor: resupport riscv64 experiment

[liulog]

记录 axvisor 实践过程

Task List

• ArceOS 启动
• linux 虚拟机启动
• 中断支持
• 虚拟中断控制器支持
• ArceOS + linux 支持
• fs feature 支持

[liulog]

Quick Start：

基于 next2 分支

需要先安装：ostool，否则会遇到 caro 没有 osrun 命令相关报错

# 从 crates.io 安装
cargo install ostool

尝试在 qemu 中启动：在 axvisor 中创建 tmp/rootfs.img (rootfs.img应该是要存放虚拟机配置文件、镜像和设备树等？还不确定）

参考：https://arceos-hypervisor.github.io/axvisorbook/docs/design/build

cargo xtask defconfig qemu-aarch64
cargo xtask build
cargo xtask qemu

PS：axvisor 目前的构建部分又是一个相当复杂的工程，选择了 cargo xtask，这也是我第一次接触 xtask，加上 axvisor 文档文档不足，对于 quick start 来说需要费一些功夫

Next Step：

现在 axvisor 的 aarch64 的支持比较全，所以选择 qemu-aarch64 作为实验基础平台。

1. 搞清楚 axvisor 的虚拟机相关文件的使用，启动虚拟机（感觉应该放置在 rootfs.img 中？）
2. 了解一下 virtio-console/uart 的驱动

[liulog]

Current progress:

qemu-system-aarch64 上可以成功启动 arceos-helloworld：

其中 arceos-helloworld 为一个 unikernel，对于 qemu-system-aarch64 来说，其运行在 0x40200000，因此就要求必须 axvisor 将其加载到 GPA=0x40200000 处执行。

arceos-aarch64-qemu-smp1.toml 中主要变化如下：

#
# Vm kernel configs
#
[kernel]
# The entry point of the kernel image.
entry_point = 0x4020_0000                                    # --> entry_point
# The location of image: "memory" | "fs".
# load from memory.
image_location = "fs"                                             # --> 这里统一从 fs 中加载，需要配置 fs feature
# The file path of the kernel image.
kernel_path = "/guest/helloworld_aarch64-qemu-virt.bin"  # --> rootfs.img (使用默认的 fat32 格式) 中的位置
# The load address of the kernel image.
kernel_load_addr = 0x4020_0000                           # --> kernel_load_addr
# The file path of the device tree blob (DTB).
#dtb_path = "path/aarch64-qemu-gicv3.dtb"
# The load address of the device tree blob (DTB).
dtb_load_addr = 0x4000_0000                               # --> 要在内存范围内

## The file path of the ramdisk image.
# ramdisk_path = ""
## The load address of the ramdisk image.
# ramdisk_load_addr = 0
## The path of the disk image.
# disk_path = "disk.img"

# Memory regions with format (`base_paddr`, `size`, `flags`, `map_type`).
# For `map_type`, 0 means `MAP_ALLOC`, 1 means `MAP_IDENTICAL`.
memory_regions = [                                                    # --> 这里配置为 MAP_ALLOC, 同时base_paddr 配成 0x4000_0000
  [0x4000_0000, 0x4000_0000, 0x7, 0], # System RAM 1G MAP_IDENTICAL
]

PS：对于 arceos-helloworld 这个 unikernel 来说不包含任何 DMA 相关内容，可以使用 MAP_ALLOC，即 GPA != HPA，这样无需修改 arceos-helloworld 即可在 axvisor 上跑起来，如果用 MAP_IDENTICAL 可能修改更为麻烦，这里就足够用了

其余部分不改，配置文件中将设备树根节点下的所有设备都 passthrough，摘除了 pcie 的 passthrough，除必要的 gic 外，没有其余的要 emu 的 device

Next Step:

1. 尝试启动 linux
2. 尝试两个虚拟机

[liulog]

经过第一次讨论，感觉为 axvisor 重新支持 riscv64 的工作更有意义，这里修改为记录支持 riscv64 的实践

[liulog]

URL：https://github.com/liulog/axvisor

当前进度

初步支持 axvisor 在 riscv64 环境下的启动：

当前问题

执行 cargo xtask qemu 时，axvisor 有时可以正常进入，有时存在缺页异常退出，待查看

其他待做内容

modules/axruntime/lib.rs 下关于 riscv 获取 cpu_count 的逻辑还没更改

pub fn cpu_count() -> usize {
    let mut cpu_count;

    cfg_if::cfg_if! {
        if #[cfg(all(target_arch = "x86_64", target_os = "none"))] {
            cpu_count = axplat_x86_qemu_q35::cpu_count()
        } else if #[cfg(target_arch = "aarch64")] {
            cpu_count = somehal::mem::cpu_id_list().count()
        } else {
            cpu_count = 1;
        }
    }

    if let Some(smp) = smp() {
        cpu_count = smp.min(cpu_count);
    }

    cpu_count
}

[liulog]

我最终发现是因为启用了 SMP，但是起初并没有正确配置 SMP

从报错信息可知，是 fault_vaddr = 0，也就是说 axvisor 尝试往 VA=0 的地方写入内容产生了缺页异常，从链接器脚本可知 0 处放的大概是 percpu 数组。同时发现 boot hart id = 0 正常，boot hart id != 0 异常，很有可能。

    . = ALIGN(4K);
    _percpu_start = .;
    _percpu_end = _percpu_start + SIZEOF(.percpu);
    .percpu 0x0 : AT(_percpu_start) {                                        ===>   这里指示虚拟地址为 0x0，可能有关
        _percpu_load_start = .;
        *(.percpu .percpu.*)
        _percpu_load_end = .;
        . = _percpu_load_start + ALIGN(64) * SMP;
    }
    . = _percpu_end;

当前对于 riscv64 来说，使用的仍然是 axplat 中 axconfig.toml 中解析参数，这里起初想采用类似 x86 那边的 extern 获取 SMP 的值，但是对于 riscv64 来说，超出了可访问范围，会出现类似如下的报错：

relocation R_RISCV_PCREL_HI20 out of range: 66584013 is not in [-524288, 524287]

由于从 axconfig.toml 中指定了内容，其中包含 cpu-num 的配置，故索性采用 config::plat::CPU_NUM 来返回 cpu_count

// platform/riscv64-qemu-virt/src/lib.rs
pub fn cpu_count() -> usize {
    config::plat::CPU_NUM
}

同时为了让链接器脚本正确知道 SMP，还需要在 configs/board/qemu-riscv64.toml 中为其指定 smp=4

cargo_args = []
features = [
    "axstd/myplat",
    "ept-level-4",
    "axstd/bus-mmio",
    # "fs",
]
log = "Info"
target = "riscv64gc-unknown-none-elf"
to_bin = true
vm_configs = []
smp = 4

当前结果

可以正常在 smp=4 情况下启用 axvisor

[liulog]

遇到的一些问题

riscv_vcpu/src/vcpu.rs 的 vmexit_handler 逻辑存在问题，对于硬件辅助虚拟化的 riscv 来说，虚拟机运行在 VS-mode，处理的应该是来自 VS-mode 的 ecall 以及 VM 产生的 Load/Store GuestPageFault，而原本的 vmexit_handler 的逻辑竟在 SuerpvisorEnvCall 和 Load/Store Pagefault 处理，不合理。

将其修改成如下：虚拟机相关退出处理 VirtualSupervisorEnvCall 以及 Load/Store GuestPageFault.

impl<H: AxVCpuHal> RISCVVCpu<H> {
    fn vmexit_handler(&mut self) -> AxResult<AxVCpuExitReason> {
         ....
        match trap {
            Trap::Exception(Exception::VirtualSupervisorEnvCall) => {
                 ....
            }
            ......
            Trap::Exception(gpf @ (Exception::LoadGuestPageFault | Exception::StoreGuestPageFault)) => {
                ....
            }
            _ => {
                panic!(
                    "Unhandled trap: {:?}, sepc: {:#x}, stval: {:#x}",
                    scause.cause(),
                    self.regs.guest_regs.sepc,
                    self.regs.trap_csrs.stval
                );
            }
        }
    }

当前效果

PS: arceos 根据 toml 配置文件进行配置，而不是设备树，这里使用了一个不使用任何设备的简易的 kernel 作为虚拟机，无中断，无 mmio-regions。

但会偶发性地产生 fault_vaddr=VA:0x0 (WRTIE) 的错误，这是不合理的，类似之前 0x0 Page Fault，暂未发现具体原因，现象如下：

需要进行查看

[liulog]

注意一个重要配置：

• MAP_ALLOC: 由 Host 负责，随机分配内存，即 GPA 为指定值，HPA 由 Host 映射到随机分配
• MAP_IDENTICAL: 由 Host 负责 1:1 给 guest 映射内存，GPA 不固定，但 GPA==HPA
• MAP_RESERVED: 将 Host 中一块标记为 reserved 的内存完全 1:1 映射给 guest，起始地址 GPA 为指定值，GPA==HPA

PS：对于系统中存在 DMA 外设（blk, net, etc.）的系统来说，在当前没有 IOMMU 的情况下，要保证 GPA==HPA，比如当前的 Linux，不能使用 MAP_ALLOC，要使用 MAP_IDENTICAL/MAP_RESERVED，对于没有 DMA 外设的系统来说可以使用 MAP_ALLOC，比如一个仅使用串口设备的 ArceOS。

for memory in &vm_create_config.kernel.memory_regions {
        match memory.map_type {
            VmMemMappingType::MapAlloc => {
                vm.alloc_memory_region(
                    Layout::from_size_align(memory.size, ALIGN).unwrap(),
                    Some(GuestPhysAddr::from(memory.gpa)),
                )
                .expect("Failed to allocate memory region for VM");
            }
            VmMemMappingType::MapIdentical => {
                vm.alloc_memory_region(Layout::from_size_align(memory.size, ALIGN).unwrap(), None)
                    .expect("Failed to allocate memory region for VM");
            }
            VmMemMappingType::MapReserved => {
                info!("VM[{}] map same region: {:#x?}", vm.id(), memory);
                let layout = Layout::from_size_align(memory.size, ALIGN).unwrap();
                vm.map_reserved_memory_region(layout, Some(GuestPhysAddr::from(memory.gpa)))
                    .expect("Failed to map memory region for VM");
            }
        }
    }

[liulog]

PS: 目前为了快速验证 Linux，当前未配置中断控制器，也没有配置任何 DMA 相关设备，使用 MAP_ALLOC，并添加了设备树的加载

对于 riscv 来说，axvisor 中没有加载设备树，为其添加设备树

目前来说，Linux 可以正常识别设备树，但是出现 Timer extension is not available ， SBI 扩展相关内容

接下来需要处理一下这个问题

[liulog]

axvisor 提供的是 sbi lagacy 的 timer 扩展，而我使用的 linux 内核并没有开启 CONFIG_RISCV_SBI_V01，导致 linux 使用新版的 time 扩展，而弃用了 lagacy 的扩展，导致出现了扩展不支持，将 linux 内核的该选项配置上。

当前进展：

PS: 暂时未使用中断，未提供虚拟中断控制器，仅提供一个 uart 设备，并且是轮询的方式。

[liulog]

当前 master 分支的 config 中采用的中断 passthrough 直接将中断发送到 EL1，即没有 vIRQ。
但这种情况仅对 arm 有效，riscv 不支持这种配置，所有的中断信号都会路由到 M/S-mode，必须由软件注入到 VS-mode。

        if !config.passthrough_interrupt {
            // Set HCR_EL2.IMO will trap IRQs to EL2 while enabling virtual IRQs.
            //
            // We must choose one of the two:
            // - Enable virtual IRQs and trap physical IRQs to EL2.
            // - Disable virtual IRQs and pass through physical IRQs to EL1.
            hcr_el2 += HCR_EL2::IMO::EnableVirtualIRQ + HCR_EL2::FMO::EnableVirtualFIQ;
        }

因此 riscv 必须实现 inject_interrupt，将中断投递到 VS-mode。

[liulog]

实现 context 中的 claim/complete 模拟可以提供一些中断注入的必要条件，添加 PLIC Partial Passthrough 的支持（类似 arm vgic）

                EmulatedDeviceType::PPPTContext => {
                    #[cfg(target_arch = "riscv64")]
                    {
                       // TODO: this.add_mmio_dev() 
                        info!(
                            "PPPT Global initialized with base GPA {:#x} and length {:#x}",
                            config.base_gpa, config.length
                        );
                    }
                    #[cfg(not(target_arch = "riscv64"))]
                    {
                        warn!(
                            "emu type: {} is not supported on this platform",
                            config.emu_type
                        );
                    }
                }

[liulog]

补充一点信息：使用 PLIC 的 riscv 平台必须在 hypervisor 进行 vPLIC 的模拟。

假设 hypervisor 将 PLIC 部分直通给虚拟机，虚拟机会操作 claim/complete 寄存器，如果 hypervisor 只是简单的 inject，那么当 hypervisor 返回虚拟机后，马上因为 S-mode 的外部中断而 vmexit，因为 hypervisor 没有执行 claim，这就导致 cpu 中的 eip 位没有清除，当 hypervisor 返回虚拟机（由于恢复了 S-mode 的中断使能，那么就会直接立刻产生 vmexit），这样就会导致一种 HS-VS 之间切换的“死循环”，这是我们不想要的。

所以必须由 hypervisor claim 中断，记录中断号，并将中断号写入到 vPLIC 中，然后返回虚拟机时注入中断，其反映在 eip 位上，这应该是 riscv 使用 PLIC 时的方案。

PS: Arm gic 可以将中断路由到具体的 PE，即 cpu core，具体哪个特权级处理，是由 arm 的系统寄存器配置的，可以配置是 EL1 or EL2 处理中断，而 riscv plic 会将中断路由到具体的 context（hart, privilege），比如某个 hart 的 M/S-mode，对于虚拟化场景下，VS-mode 不能直接收到来自 PLIC 的外部中断（尽管把 PLIC 直通给它），必须由 H 扩展注入。

[liulog]

另一个问题：

// axvm/src/vm.rs
                AxVCpuExitReason::MmioRead {
                    addr,
                    width,
                    reg,
                    reg_width: _,
                    signed_ext: _,
                } => {
                    let val = self.get_devices().handle_mmio_read(*addr, *width)?;
                    vcpu.set_gpr(*reg, val);
                    true
                }

对于 arm 来说或许没有问题，但是 riscv 会有一些问题：

// riscv_vcpu/src/vcpu.rs
    /// Set one of the vCPU's general purpose register.
    fn set_gpr(&mut self, index: usize, val: usize) {
        match index {
            0..=7 => {
                self.set_gpr_from_gpr_index(GprIndex::from_raw(index as u32 + 10).unwrap(), val);
            }
            _ => {
                warn!(
                    "RISCVVCpu: Unsupported general purpose register index: {}",
                    index
                );
            }
        }
    }

这两个位置不匹配，导致如果 mmio read/write 会有异常，mmio read/write 用的是整个寄存器组的索引，0-31，而 set_gpr 只允许使用 10-17 这 8 个寄存器，而且索引对不上，需要解决。

[liulog]

当前进展

初步支持中断注入 + 虚拟中断控制器（Partial Passthrough）

PS: 当前的支持比较初级，当前存在部分字段硬编码的问题等，灵活性有限，需要【设计 Interface 等】

目前效果如下，串口中断正常：