关于移植 ArceOS 以及相关组件化内核到 seL4/reL4 上的思考

[croakexciting]

来源于向老师的题目，如何在尽量不侵入的情况下，将 ArceOS 及相关的组件化内核以用户态任务的形式跑在 seL4/reL4 系统上。结合 seL4 系统的安全性和 ArceOS 的组件化开发优势。

1. 思考

这个题目给我的第一反应是，seL4 似乎起到的是 hypervisor 的作用。只不过都往下降了一个特权级。

仔细考虑后，我感觉这个做法可能存在如下优势和劣势

优势

1. 可以把内核组件拆成一个个独立运行的服务，这样一个服务挂了，不影响其他的操作系统服务
2. seL4 独特的 capability 设计，似乎保证了一些安全性。当然我没想明白对 unikernel 有啥用，也许对组件化宏内核有用。但至少可以确保运行的稳定性，结合第一条，系统稳定性应该是提高的。

劣势

1. 效率问题，老生常谈的微内核效率问题，但是在这可能更严重。我们以一个 syscall 为例 (当然 unikernel 不存在 syscall 的问题，这里我们以 starry 等宏内核做分析)，syscall 首先要进入内核态，内核态会重定向到 kernel-thread，kernel-thread 处理 syscall 需要给别的服务发请求，比如 write 这种，需要给 blk-device 或者 uart 发送请求，这就多了一道 IPC。当然我们可以把所有组件都集成为一个进程，都是函数调用，但这样就没法实现上述的第一条优势了。这中间有个效率和稳定性的取舍。
2. 可靠性功能存疑，虽然 seL4 保证绝对可靠，但是运行在它上面的 kernel-thread 不一定，如果 kernel-thread 挂了，相当于整个操作系统也基本没啥用了，seL4 的 kernel 再可靠似乎也没啥用。
3. 调度策略，内存分配策略的冲突。

2. 目标

我计划以 arceos 模块为单位进行修改，最后针对修改的模块看能否兼容 arceos 主仓库。

我目前确认一定会修改的是 axhal 和 axalloc ，其他的还待开发过程中确认。

axhal 和 axalloc 是和硬件资源分配相关的，我的目标就是在其中实现适配 seL4 系统的资源分配和管理功能。

第一阶段目标是用 单核，单任务的配置，把 arceos 的三个例子运行起来，后面待定

[croakexciting]

在移植的过程中，目前发现有如下问题

1. 必须要用 srv-gate crate，这样可以用 rel4-linux-kit 中定义好的服务调用功能，但是 srv-gate 中用到了堆，如果 arceos 不开堆就会报错。
2. 针对上面问题，如果想用堆，按照 rel4-linux-kit 中的做法时使用 define_heap! ，但是这个宏用到了 seL4-runtime，很多和 axruntime 是重复定义的，所以绝对不能用。

对于第一个问题，我觉得 arceos 上迟早是需要用到堆的，所以倒没有必要修改 srv-gate 中和堆相关的代码。因此我准备先把 axalloc 在 seL4 上的实现做了，在 arceos 可以使用堆相关功能

[croakexciting]

目前 arceos 上关于内存分配和管理的设计和 seL4 是冲突的，因此首先考虑解决该问题。主要冲突点如下

1. arceos 上采用 固定偏移 map 的设计，但是运行在 seL4 上时，它是一个用户态进程，没办法要求自己被加载在哪段物理内存上
2. arceos 上 allocator 初始化时，获取大段连续物理内存并管理。同样的原因，运行在 seL4 上时，没办法获取连续物理内存
3. seL4-linux-kit 中一些功能依赖堆，去掉堆之后，似乎不太好用，因此要求 arceos 初始化时就被分配了堆

针对以上问题，目前做了以下内存相关设计

1. axruntime 中禁用 axmm::init_memory_management，其中设计很多页表等操作，实在无法剥离。因此我在 axhal 中单独写了一个内存初始化函数，放弃了 axmm 的功能
2. sel4-linux-kit 在创建进程时，给进程在固定位置 0x2000_0000 分配一块 2M 的大页。arceos 在启动时直接使用该段内存作为堆，进行初始化
3. sel4-linux-kit 启动时给进程分配一块最大的 untyped cap，arceos 启动后使用该段内存进行内存初始化等操作。目前基本上就是将 untyped cap 全部分配为 large_frame 并映射。为了保持地址的连续性，也就是大页和大页之前紧挨着，这块 untyped cap 上只放大页，其他所有的能力放置在另外一个 4K 大小的 untyped 区域上。也就是说，root-task 会给进程分配一块很大和一块 4K 大小的 untyped cap
4. arceos 在内存初始化时，会用 untyped cap 分配出来的内存区域作为 axalloc 使用的区域，初始化时的那段内存不会再被用到，只存放着初始化时在上面产生的一些对象。由于这些对象都是静态的，应该不涉及 dealloc 的问题。
5. 外设地址由 root-task 实现映射到指定虚拟地址，arceos 直接使用映射后的虚拟地址，应该不用使用物理地址了
6. DMA 是个问题，因为确实需要直到 DMA 区域指定的物理地址。arceos 中是从 axalloc 中直接分配一块内存作为 DMA，然后通过 virt_to_phys 找到物理地址，这对 arceos 是很简单，减去 offset 即可。为了不更改这部分逻辑，在 hal 中修改了 virt_to_phys 和 phys_to_virt 的实现，如果 paddr 在上述说的很大的那块 untyped cap 内，由于这是由 arceos 自己分配的，所以很容易找到对应 vaddr。由于这块 untyped cap 上面只有 large frame，所以虚拟地址在上面是连续的，等同于 fixed offset mapping。如果 paddr 不在这个范围中，比如 0x10000 这种其实地址，那代表肯定不是 DMA，知道不知道物理地址其实没多大关系，因为 axmm 已经被禁用了，所以直接返回 vaddr 就可以，只是为了查找时不报错。

    fn virt_to_phys(&self, vaddr: usize) -> usize {
        log::info!("virt_to_phys: vaddr = {:#x}", vaddr);
        let vstart = (vaddr / LARGE_PAGE_SIZE) * LARGE_PAGE_SIZE;
        if let Some(range) = self.regions.lock().get(&vstart) {
            let pstart = range.start;
            return pstart + (vaddr - vstart);
        }
        
        vaddr
    }

    fn phys_to_virt(&self, paddr: usize) -> usize {
        for (vstart, range) in self.regions.lock().iter() {
            if range.contains(&paddr) {
                return vstart + (paddr - range.start);
            }
        }
        
        paddr
    }

如上所述，arceos 现在内存分为四部分

1. elf 文件中定义段，root-task 会将其映射并加载，并创建栈和 IPC Buffer ，是基本固定的部分，完全由 root-task 创建
2. 一个初始化时使用的堆空间，同样由 root-task 分配并映射到指定虚拟地址，供初始化时使用
3. 一个巨大的 untyped cap，直接给到 arceos，由自己维护。初始化将该段内存连续化映射后，交给 axalloc
4. 一个 4K 的 untyped cap，用来放 large page 之外的能力，比如上述映射过程中需要的页表

目前在几乎只改 hal 的情况下，将 arceos 移植到 rel4-linux-kit 框架中使用，但仍有很多细节需要打磨

同时，multi_task 还不知道怎么适配，我会继续看看这块

[yfblock]

3. 是一个很好的想法，我之前也考虑过，但是问题是 一旦将 untyped cap 转换为 frame cap 后如何确保它能够 convert back，在 frame 不够用的时候逐渐的将 untyped 都分给 frame 后，如何申请 tcb 和 cnode 等其他 cap。

不过这个解决方案很好，很适用于当前的场景下，对于宏内核现有架构确实很好用。但是面临的问题就是如果在内存不够的时候随着不断的将内存分配 frame cap 后，如何处理这种 “内存碎片“的问题。

[yfblock]

其实可以将 untyped 分为 12bits 的大小管理，frame allocator 并不直接管理 frame cap，而是管理 12bits 的 untyped 的 cap，后续 申请 tcb 等其他 cap 也许可以从这里申请。

[croakexciting]

由于现在还没考虑到 arceos 创建新进程的情况，所以是把 3 中的 untyped 都分配成 large frame，供 arceos 自己使用。同时为了保持地址连续，这块 untyped 区域只分配 large frame，其他 cap 我计划是放到 4 中提到的 4K 的 untyped。

这样做的好处是，3 的 untyped 区域几乎等同于物理内存了 （地址连续，和虚拟地址之间关系是固定 offset）

但是，如果在多任务情况下怎么办，确实还没有考虑清楚。如果一块 frame 可以被 map 到两个 vspace 中，我感觉问题迎刃而解了。在 arceos vspace 中，可以访问这段内存，在 arceos 创建的任务中，也可以访问这段。我感觉似乎是可行的，只是一些细节需要考虑

[croakexciting]

相对内存问题，multitask 的问题，我认为更加复杂，主要是以下几点

1. 移植到 sel4 上后，arceos 无法像正常操作系统一样，通过 context 来代表一个 task
2. task 切换方式也要变，之前直接通过寄存器切换上下文即可，现在怎么切呢，没想明白
3. 创建 task，是创建 seL4 task 吗，那相当于是创建 seL4 进程了。这样 改动量感觉很大，任务之前通信效率也大幅降低
4. 最好是在一个 seL4 task 里面搞定 multitask，可是 seL4 也不支持线程机制，难道用协程吗，可是也不太懂协程，不清楚能否实现
5. 目前感觉，由于 arceos 中的 multitask 本质上是多个函数，而不是进程，所以直觉是，协程让我感觉更合理。但是拓展到宏内核上，也许又不同

目前思路有点混乱，所以上面几点写的也没什么逻辑，我预计会先了解下用协程实现的可能性，这是我目前的计划。

[croakexciting]

更新下这个问题

切换上下文失败是由于 tpidr_el0 寄存器操作造成的，我在 context switch_to 切换中将 tpidr_el0 寄存器去掉了之后，multitask 正常了，httpserver 也可以正常运行起来。

当然这个解决方案很粗糙

1. tpidr_el0 和 tls 相关，如何解决 tls 问题，需要看一下。但是我觉得 tls 也许可以用别的寄存器表示？
2. 无法解决宏内核多进程的问题，我觉得宏内核中，创建一个进程还是需要建立一个 seL4 进程

总的来说，协程是不需要的，因为协程本质上也是用户态切换任务，这部分 arceos 已经实现了

[croakexciting]

遇到一个新问题，就是 rel4-linux-kit 中的 linkme 段，它们环绕在 percpu 段的周围，导致执行了 percpu 相关操作是，会覆盖这些段，从而报错。

有一个解法是让 percpu 前后留一些空白区域，我目前是 4K 对齐，可以解决。但仍然感觉是临时方案，随时有内存相关的问题。有什么办法可以把这些 linkme 段统一到一起吗，我尝试改了链接脚本，会报错。

  [ 7] linkme_IRQ        PROGBITS         0000000000128080  00029080
       0000000000000000  0000000000000000 WAR       0     0     8
  [ 8] linkm2_IRQ        PROGBITS         0000000000128080  00029080
       0000000000000008  0000000000000000  AR       0     0     8
  [ 9] linkme_PAGE_FAULT PROGBITS         0000000000128088  00029088
       0000000000000000  0000000000000000 WAR       0     0     8
  [10] linkm2_PAGE_FAULT PROGBITS         0000000000128088  00029088
       0000000000000008  0000000000000000  AR       0     0     8
  [11] linkm2_EVENT[...] PROGBITS         0000000000128090  00029090
       0000000000000008  0000000000000000  AR       0     0     8
  [12] linkm2_UART_IMPLS PROGBITS         0000000000128098  00029098
       0000000000000008  0000000000000000  AR       0     0     8
  [13] linkm2_BLK_IMPLS  PROGBITS         00000000001280a0  000290a0
       0000000000000008  0000000000000000  AR       0     0     8
  [14] linkm2_FS_IMPLS   PROGBITS         00000000001280a8  000290a8
       0000000000000008  0000000000000000  AR       0     0     8
  [15] .percpu           PROGBITS         0000000000129000  0002a000
       0000000000129040  0000000000000000  WA       0     0     4096
  [16] linkme_EVENT[...] PROGBITS         0000000000252040  00153040
       0000000000000010  0000000000000000 WAR       0     0     8
  [17] linkme_UART_IMPLS PROGBITS         0000000000252050  00153050
       0000000000000020  0000000000000000 WAR       0     0     8
  [18] linkme_BLK_IMPLS  PROGBITS         0000000000252070  00153070
       0000000000000000  0000000000000000 WAR       0     0     8
  [19] linkme_FS_IMPLS   PROGBITS         0000000000252070  00153070
       0000000000000000  0000000000000000 WAR       0     0     8

[croakexciting]

目前已经可以运行 httpclient, httpserver, helloworld 三个例子，基本上只改动了 axhal 和几个底层相关的 crate

改动 commit 如下
arceos: arceos-org/arceos@91cdb00
kernel_guard: croakexciting/kernel_guard@f0c503d
axcpu: croakexciting/axcpu@63c2f34
percpu: croakexciting/percpu@72aa7a2

目前看起来，如果只是 arceos unikernel 的功能和 feature，适配应该问题都不大。

但是涉及到宏内核的功能，看起来都很复杂，需要好好思考如何设计。

[croakexciting]

由于 Arceos 对 hal 和 platform 部分进行了大调整，将 platform 独立出去，因此我同步进行了调整。

调整后，新增了 axplat-aarch64-sel4 crate https://github.com/reL4team2/arceos/tree/croak/sel4_porting/platforms/axplat-aarch64-sel4

现在看起来更加干净了，arceos 中只在 modules/axhal/src/percpu.rs 和 modules/axruntime/src/lib.rs 中做了微小改动，通过 asuser 编译选项打开或者关闭。

改动 commit reL4team2/arceos@f2e29f3#diff-557a9ff9346af8506692e25351145816cb1ca3e3ba51aaf288a37325d920bb9e

[croakexciting]

关于中断设计如下：

我们的目标是，让 arceos 可以接收注册到 seL4 中的中断，并且可以作相应处理，最好是可以兼容目前的 seL4 配置。按照这个目标，衍生出以下两个问题需要解决

1. arceos 作为一个 seL4 用户态进程，如何接收到中断
2. arceos 如何在用户态处理中断产生后的上下文保存和恢复功能

1. arceos 如何接收到中断

和在裸机上运行不同，运行在 seL4 上的 arceos 是无法设置中断处理函数，并且由硬件在中断触发的时候跳转到中断处理函数。seL4 的中断机制是内核在触发中断时，向用户态发送对应的 notification。因此需要用户态进程不断轮询该 notification，判断是否有中断产生。

为了减少在 arceos 中的改动，让 arceos 仍然在不知道的情况下跳转到中断处理函数。我们需要另一个进程监听中断，并且让 arceos 跳转到中断处理函数。

1.1 辅助进程监听中断

我暂且使用 root-task 作为这个辅助进程，而不是另外创建一个。
参考 yjb 之前在 kernel-task 中的设计，我在 root-task 中创建一个 notification，并且加上 badge 后注册到对应的中断中。比如下面是 timer 中断监听。

  sel4::init_thread::slot::IRQ_CONTROL
      .cap()RegisterIRQ
      .irq_control_get(GENERIC_TIMER_PCNT_IRQ as u64, &TIMER_IRQ_SLOT.abs_cptr())
      .unwrap();

// TIMER_IRQ_NOTIFY 是由一个全局 notification mint 产生的
// 这样不同的中断可以对应不同的 badge，但是只需要监听一个 notification 即可
  TIMER_IRQ_SLOT
      .cap::<sel4::cap_type::IrqHandler>()
      .irq_handler_set_notification(*TIMER_IRQ_NOTIFY)
      .unwrap();

在原有的 root-task 轮询监听函数中增加了对应 badge 的监听。目前示例中只监听了 timer 中断，后面应该会改成监听某个高位，这样可以监听所有中断。

    pub fn waiting_and_handle(&mut self, ib: &mut IpcBuffer) -> ! {
        let rev_msg = MessageInfoBuilder::default();
        let swap_slot = OBJ_ALLOCATOR.allocate_slot();
        loop {
            if badge == u64::MAX {
                ......
                continue;
            }

上述就可以实现对某个中断的监听。现在 demo 中是默认监听了 timer 中断，后面需要改成注册的方式，修改下现有的 RegisterIRQ IPC 方法即可

1.2 辅助进程处理中断

在辅助进程中，主要目的就是让 arceos 跳转到中断处理函数。这里我们可以使用 tcb_write_all_registers syscall，修改 arceos 进程的 pc，实现跳转。由于 arceos 需要知道跳转之前的 pc，因此 root-task 需要把这个值传递给 arceos，暂且是放在 x0 中，但是这样会破坏 arceos 原有上下文，后续考虑使用共享内存或其他方式传递。

// 读取 arceos 当前上下文
let mut ctx = tcb.tcb_read_all_registers(true).unwrap();
// 获取 pc 值
let pc = *ctx.pc() as u64;
// 把中断处理函数地址设置为 pc
*(ctx.pc_mut()) = *fault_ip as u64;
// 把原有的 pc 值保存到 x0
*(ctx.gpr_mut(0)) = pc;
// 更新上下文，并且处罚 arceos resume
tcb.tcb_write_all_registers(true,&mut ctx).unwrap();

上述操作，可以让 arceos 跳转到 trap 处理函数

1.3 TODO

总的来说，还有以下细节需要设计

1. pc 和 badge 值如何传递，我希望通过 badge 值代表对应中断，让 arceos 可以分类处理。现在放在上下文中传递的方式会破坏原有上下文，肯定是不可靠的。
2. 中断的注册和管理的细节，我现在是只考虑 arceos 一个进程，如果有多个进程，那可能其他进程是不要进入中断处理函数的。如何区分处理这些进程，需要设计

2. Arceos 中如何处理中断

2.1 上下文保存和恢复

arceos 中最关键的设计是，如何在中断处理函数执行完成后，跳转回到中断之前位置，继续执行。

我们可以参照 trap 进入 kernel 并且退出的过程，分析下不同的点，并做相应改动

1. kernel 可以读写更多的寄存器，用户态基本只能读写 x0~x30
2. 进入 kernel 的时候，sp 指向的肯定是栈顶，内核栈是干净的，但是我们上述设计中，在切到中断执行函数时，栈是在使用中的。
3. 无论什么架构，我们都可以把 pc 设置到一个特殊寄存器 (sepc, sp_el0 等)，然后通过 eret 跳转回去。用户态不存在这些机制。

明确上述三点不同后，我们就可以针对性的做如下修改了

1. 在 trap 处理函数中，我们只保存 x0-x30 sp 这 32 个寄存器，其他的也无需保存。
2. 虽然栈不干净，但是我们只需要保证在恢复的时候，把 sp 恢复到原有值。在中断处理函数中，无论怎么使用当前的栈空间都是可以的
3. 不需要使用 ret 返回，直接 br 跳转回去即可

// trap 实现
// save all sel4 context register
__alltraps:
    sub     sp, sp, #16 * 16
    stp     x0, x1, [sp, #16 * 0]
    stp     x2, x3, [sp, #16 * 1]
    stp     x4, x5, [sp, #16 * 2]
    stp     x6, x7, [sp, #16 * 3]
    stp     x8, x9, [sp, #16 * 4]
    stp     x10, x11, [sp, #16 * 5]
    stp     x12, x13, [sp, #16 * 6]
    stp     x14, x15, [sp, #16 * 7]
    stp     x16, x17, [sp, #16 * 8]
    stp     x18, x19, [sp, #16 * 9]
    stp     x20, x21, [sp, #16 * 10]
    stp     x22, x23, [sp, #16 * 11]
    stp     x24, x25, [sp, #16 * 12]
    stp     x26, x27, [sp, #16 * 13]
    stp     x28, x29, [sp, #16 * 14]
    mov     x0, sp
    stp     lr, x0, [sp, #16 * 15]
    // 无缝衔接 arceos 原本的中断处理函数，只是把 trap 替换了而已
    bl       irq_handler

    ldp     lr, x0, [sp, #16 * 15]
    mov     sp, x0

    ldp     x28, x29, [sp, #16 * 14]
    ldp     x26, x27, [sp, #16 * 13]
    ldp     x24, x25, [sp, #16 * 12]
    ldp     x22, x23, [sp, #16 * 11]
    ldp     x20, x21, [sp, #16 * 10]
    ldp     x18, x19, [sp, #16 * 9]
    ldp     x16, x17, [sp, #16 * 8]
    ldp     x14, x15, [sp, #16 * 7]
    ldp     x12, x13, [sp, #16 * 6]
    ldp     x10, x11, [sp, #16 * 5]
    ldp     x8,  x9,  [sp, #16 * 4]
    ldp     x6,  x7,  [sp, #16 * 3]
    ldp     x4,  x5,  [sp, #16 * 2]
    ldp     x2,  x3,  [sp, #16 * 1]
    ldp     x0,  x1,  [sp, #16 * 0]

    add     sp, sp, #16 * 16
    br      x0

通过上述设计，arceos 中原本的中断功能设计仍然可用，因为入口和之前一样，还是 irq_handler

2.2 中断 cap 相关设计

arceos 中 irq ack 的方式也需要修改，从直接操作 gic，改成操作 sel4 的 irq capability。这部分原理上没什么难度，只需要后续细化设计。

2.3 时钟等一些细节的移植实现

在 demo 实现的过程中，发现有一些底层和架构相关的实现需要修改，比如 timer 等等。这部分在后续实现是进行记录。

[yfblock]

目前考虑 可能有一些问题

1. 如果是 利用 root-task 作为中断处理程序，如何考虑可能产生的死锁问题？如果是 起一个 arceos 的线程，那么就可以用共享变量来判断是否应该打断程序
2. 有没有必要再存在汇编的 trap? 因为中断处理程序已经可以代为保存上下文状态，在上下文处理结束后发一个 ipc，让其帮忙恢复是不是更好？汇编出错的概率比较大，能尽量少的存在就尽量少的存在？

[croakexciting]

根据上次的讨论，做了如下工作

1. 在 arceos 中启动一个 seL4 thread，循环监听中断 notification，并根据中断号执行对应的中断处理函数
2. 实现了 arceos 中原本的中断相关接口，保持原本的使用方式不变
3. 增加了 arceos 中创建和管理 seL4 thread 的模块，后续尝试对接到 axtask 中

有一个修改值得一说，关于 percpu 变量功能的修改。arceos 中原本是使用 tpidr_el1 寄存器存储 percpu 区域的地址，我之前尝试改成 tpidr_el0 在用户态使用。但是 seL4 中会使用该寄存器指定每个任务的 tls 区域，产生冲突。在不能修改 seL4 的前提下，我只能使用 x28 寄存器，并且在编译选项中，告诉编译器不要使用 x28 寄存器。

关于 thread，目前的做法是，只和父进程共享 vspace，其他的重新创建。在开始任务之前，会从 x8 寄存器传入该线程分配的 ipc buffer 地址，由该线程进行 ipc 的初始化等操作。这些初始化固定操作定义在一个过程宏当中，比如中断处理线程

  #[sel4_thread_entry]
  fn irq_handler() {
      loop {
          let (_, badge) = DEFAULT_SERVE_EP.recv(());
          handle_trap!(IRQ, badge as _);
          IRQ_CAPS.lock().ack_irq(badge as _);
      }
  }

[croakexciting]

最近初步完成了 arceos task 适配 seL4 的工作，和之前提到的 multitask 方案不同，现在每个 arceos task 都是一个 seL4 task，除了共享 vspace，其他能力都是独立的。

具体的 task 创建和回收实现可以参考 https://github.com/reL4team2/arceos/blob/croak/sel4_porting2/platforms/axplat-aarch64-sel4/src/utils/task.rs

按照之前 yjb 的设计，每个 task 创建时，会分配一个固定大小的 untyped 区域，所有能力都从其中分配吗，这样方便回收。

当 arceos 初始化完成后，会产生 main 任务，gc 任务等默认任务，然后主任务会作为 event_handler，监听子任务的 ipc 请求和中断通知，中断注册和管理的实现不用改变，只是把中断监听的功能放到了主进程中。

任务创建、切换、退出都是由主任务执行，因为所有任务创建时产生的能力，都是存储在主任务的 cspace 中。换句话说，只有主任务可以访问所有任务的资源，操作所有任务。

  match msg_label {
      ServiceEvent::SwitchTask => {
          let task_ptr = read_types!(ib, usize);
          reply_with!(ib, 0);
          axtask::switch_sel4_task(task_ptr);
      }
      ServiceEvent::CreateTask => {
          let (tid, entry, stack) = read_types!(ib, usize, usize, usize);
          let task_ptr = create_sel4_task(tid, entry, stack);
          reply_with!(ib, task_ptr);
      }
      ServiceEvent::ExitTask => {
          let task_ptr = read_types!(ib, usize);
          exit_sel4_task(task_ptr);
          reply_with!(ib, 0);
      }
  }

和之前 arceos 保持一样，任何任务都可以创建任务，只是将直接创建，改成了发送 IPC 请求给主任务，由主任务代为创建

调度使用 arceos 原生的调度器，只是在 switch_to 的时候，将切换上下文，改成了通过 IPC 请求切换任务。主任务通过 suspend prev_task，resume next_task 的方式进行任务切换。

退出任务时，同样会发送 IPC 请求，由主任务对任务的 能力 资源进行回收，确保不会出现 untyped 不够，无法分配能力的情况。

这样做的缺点就是，每个任务创建和回收的效率很低，任务间切换效率也很低，但是如果用 seL4 task 的话，这些似乎无法避免。一种解决方案是混合式任务，类似线程和协程。

[croakexciting]

关于 tls 段和 linkme 段冲突的问题如下

[ 5] .tdata PROGBITS 000000000011c070 0001d070 0000000000000028 0000000000000000 WAT 0 0 16 
[ 6] .tbss NOBITS 000000000011c0a0 0001d098 0000000000000008 0000000000000000 WAT 0 0 16 
[ 7] linkme_IRQ PROGBITS 000000000011c098 0001d098 0000000000000000 0000000000000000 WAR 0 0 8 
[ 8] linkm2_IRQ PROGBITS 000000000011c098 0001d098 0000000000000008 0000000000000000 AR 0 0 8 
[ 9] linkme_PAGE_FAULT PROGBITS 000000000011c0a0 0001d0a0 0000000000000000 0000000000000000 WAR 0 0 8 
[10] linkm2_PAGE_FAULT PROGBITS 000000000011c0a0 0001d0a0

可以看到，linkme 段是完全跟在 tdata 后面的，和 tbss 段是冲突的。而 arceos 中，会在 tls 初始化的时候，将 tbss 段进行清零，拷贝等操作，就会影响到 linkme 段。

同时 rust-seL4 中的 IPC_BUFFER 地址就是一个 tbss 段的变量，初始化的时候也会设置该变量，会影响 linkme 段

改成下面 链接脚本，可以解决该问题

.tdata : ALIGN(0x10) {
    _stdata = .;
    *(.tdata .tdata.*)
    _etdata = .;
    . = ALIGN(0x10);  

    _stbss = .;
    *(.tbss .tbss.*)
    *(.tcommon)
    _etbss = .;

    . = ALIGN(0x10);        
}

[croakexciting]

记录下最近在一直多核功能时遇到的一个问题

问题描述

打开 arceos smp 功能后，发现在进行第一次调度时，会访问一个非法地址，一般是 0 或者 8 这种很小的地址。

第一步，我先通过 log 确认下是在哪几句出错的，定位到下面这句

*PREV_TASK.current_ref_mut_raw() = Arc::downgrade(prev_task.as_task_ref());

我首先怀疑是后半段，但是我改成下面后，仍然会报错，所以感觉是前半段 drop 的时候出错了

*PREV_TASK.current_ref_mut_raw() = Weak::new();

由于是第一次赋值的时候就出错了，这很奇怪，因为初始化的时候是赋值 Weak::new()，按道理这个值不应该会 drop 失败

进一步，我进行了测试，对 PREV_TASK 进行 upgrade，同样会出错，这样就可以确认是 PREV_TASK 这个值初始化后就有问题

PREV_TASK 是一个 percpu 值，初始化如下

#[percpu::def_percpu]
PREV_TASK: Weak<crate::AxTask> = Weak::new(),

我找到了该值的地址，然后 gdb 中查看了初始化之后该地址的值，发现是 0，看起来没什么问题。然后我查看了 Weak 相关的文档，发现 Weak::new() 产生的值是 -1。

之后就思考为什么初始化的值不对，排查到是因为 elf 文件加载的问题，由于 elf 加载功能实现的时候，忽略了 address 为 0 的段，导致没有复制加载 percpu 段，也就导致初始化值不对。

以上就是我调查该问题的全部过程

[croakexciting]

打开抢占调度后遇到的 panic 问题

抢占计数器不对

大概两周前，在运行 wait_queue 测例时，将调度策略设置为 rr 或者 cfs 时，发现测例运行失败，在这个断言处检查失败

    pub fn blocked_resched(&mut self, mut wq_guard: WaitQueueGuard) {
        // we must not block current task with preemption disabled.
        // Current expected preempt count is 2.
        // 1 for `NoPreemptIrqSave`, 1 for wait queue's `SpinNoIrq`.
        #[cfg(feature = "preempt")]
        assert!(curr.can_preempt(2));

arceos 中，每个任务中有一个 preempt 计数器，用于记录当前任务被执行 disable_preempt 和 enable_preempt 的次数，前者 +1 后者 -1.

发现在报错时，这个计数器是 1，通过注释可以看出，这个函数执行时，经历了两个锁，也就是 preempt 加了两次，如果是 1，那说明是从 -1 加上来的，这就很不正常了。

接着通过查找，发现第一次出现 -1 是中断中执行 preempt_resched 抢占切换造成的。进一步 debug 发现 backtrace 指向中断处理函数

#[register_trap_handler(IRQ)]
pub fn irq_handler(vector: usize) -> bool {
    let guard = kernel_guard::NoPreempt::new();
    handle(vector);
    drop(guard); // rescheduling may occur when preemption is re-enabled.
    true
}

这儿逻辑也没有问题，就是 drop(guard) 出发的抢占，完全没问题。那这样问题就集中到了 preempt_resched 函数中，首先就怀疑是任务切换时的问题，因为在任务切换前会 lock，也就是对前一个任务 preempt 计数 + 1，切换后对后一个任务 release 也就是 -1，看起来就很容易造成 preempt 计数出现 -1.

  let mut rq = crate::current_run_queue::<NoPreemptIrqSave>(); // lock
  if curr.need_resched.load(Ordering::Acquire) {
      rq.preempt_resched()
  }
// drop

分析和 arceos 任务切换的异同，原版 arceos 直接切换上下文，也就是说，原有的控制流被打断，压根不会执行到 drop 的地方，也就不会 -1，而架在 seL4 上的切换本质是通过调用 syscall 切换，执行完不会马上打断中断处理函数，而是会执行完。因此会在切换后，执行锁的 drop，导致对切换后的函数进行 preempt counter -1 的操作，造成问题

目前的解决方案时不允许再中断处理函数中切换任务，由于中断处理函数是在 管理任务 中执行的，如果想在切换时直接打断控制流，似乎只能 suspend 当前任务，但是我找不到一个别的任务可以再次将 管理任务 拉起，因此只能避免在中断中切换任务。

多核时任务刚启动出现抢占计数器不对

这个问题是由于初始化流程还未结束，就执行了 idle 任务，进一步开始调度造成的。

根本原因是，在初始化调度器后，直接将 idle 任务在 seL4 中设置为 running 状态，由于 idle 任务优先级低，我认为在初始化流程执行完之前，是不会执行 idle 的。

提前执行的原因是，初始化流程中进行中断初始化时，会注册中断，这是一个 ipc 请求，在初始化任务等待 reply 时，seL4 执行了 idle 任务，然后出错。修改方法就是完成初始化过程后，再启动 idle 任务即可