动态内存需要解决的Percpu问题

[ZR233]

1. 变量offset计算与arch强相关。

/// Generate a code block that calculates the offset of the per-CPU variable based on the inner symbol name.
pub fn gen_offset(symbol: &Ident) -> proc_macro2::TokenStream {
    // the outer pair of braces is necessary to make the result an expression
    quote! {
        unsafe {
            let value: usize;
            #[cfg(target_arch = "x86_64")]
            ::core::arch::asm!(
                "mov {0:e}, offset {VAR}", // Requires offset <= 0xffff_ffff
                out(reg) value,
                VAR = sym #symbol,
            );
            #[cfg(target_arch = "aarch64")]
            ::core::arch::asm!(
                "movz {0}, #:abs_g0_nc:{VAR}", // Requires offset <= 0xffff
                out(reg) value,
                VAR = sym #symbol,
            );
            #[cfg(any(target_arch = "riscv32", target_arch = "riscv64"))]
            ::core::arch::asm!(
                "lui {0}, %hi({VAR})",
                "addi {0}, {0}, %lo({VAR})", // Requires offset <= 0xffff_ffff
                out(reg) value,
                VAR = sym #symbol,
            );
            #[cfg(any(target_arch = "loongarch64"))]
            ::core::arch::asm!(
                "lu12i.w {0}, %abs_hi20({VAR})",
                "ori {0}, {0}, %abs_lo12({VAR})", // Requires offset <= 0xffff_ffff
                out(reg) value,
                VAR = sym #symbol,
            );
            value
        }
    }
}

实际用变量链接地址减去段基地址就可以得到，为何这样设计？

2. percpu基地址寄存器不合规范
   percpu riscv 使用 gp 寄存器保存基地址，实际编译器开启relax功能后，会编译出操作gp寄存器的代码，造成地址混乱，这个功能默认开启。riscv 手册要求用sscratch存放hart 相关内容， 不知为何使用gp？

12.1.6. Supervisor Scratch (sscratch) Register
The sscratch CSR is an SXLEN-bit read/write register, dedicated for use by the supervisor. Typically,
sscratch is used to hold a pointer to the hart-local supervisor context while the hart is executing user code.
At the beginning of a trap handler, software normally uses a CSRRW instruction to swap sscratch with an
integer register to obtain an initial working register

而axhal riscv trap 中又通过 sscratch 是否 == 0 判断 user 还是 kernel trap，需要一起修改

.section .text
.balign 4
.global trap_vector_base
trap_vector_base:
    // sscratch == 0: trap from S mode
    // sscratch != 0: trap from U mode
    csrrw   sp, sscratch, sp            // swap sscratch and sp
    bnez    sp, .Ltrap_entry_u

    csrr    sp, sscratch                // put supervisor sp back
    j       .Ltrap_entry_s

如果改为使用sscratch，对宏内核是否有影响？

[shilei-massclouds]

对第1个问题：感觉可以按此思路试一下。gen_offset就是在取指定的percpu变量在所属percpu area中的相对偏移，而Primary CPU使用的area是静态存在于.percpu这个段里面的，基于它计算获得的相对偏移对所有cpu都是一致的。原理上感觉没有问题，只是要验证一下，用rust 宏写出来的效果是否与当前实现一致。
第2个问题是否要分成两个问题：
2-1：gp寄存器的使用问题。我支持按照riscv规范来使用gp，它就应该是配合relaxing机制的专用寄存器。而且percpu crate的注释文档中也提到，在riscv中只是临时使用gp来干这个事。感觉可以参照linux的做法来实现，直接用全局数组来存各个percpu area的基地址，用的时候基于cpu id对这个全局数组查表。
2-2：sscratch的使用。感觉这个可以跟2-1分可考虑，而且这个目前可以不改，它不影响percpu的修改。这个sscratch的作用是，在用户态执行期间，它会暂存supervisor context。Linux的设计是，sscratch在用户态执行期间暂存tp，而tp寄存器指向current，即supervisor context，该context中包含对应的内核栈，返回内核态时用它重置sp；ArceOS的设计是，sscratch在用户态执行期间暂存sp的原始值，返回内核态时直接恢复重置sp。对于ArceOS，即便按照2-1修改了percpu机制，不用gp了，那current依然是percpu area中的一个变量，感觉没有什么关联。这个可以不改。

[ZR233]

初步重构percpu为arch无关： https://github.com/[ZR233/percpu](https://github.com/ZR233/percpu)