Hi Diego, On Thursday, 8 October 2026 at 02:24, Santi cluke <[email protected]> wrote:
> Hi Hakan, > > An update on the high-address work you asked for before revisiting the > trap entry: the kernel now continues bootstrap from the higher-half > alias (KERNEL_MAP_BASE). On QEMU virt with OpenSBI, the version banner > prints from a high VMA (0xffffffff80xxxxxx), so the switch works end > to end. > Thanks! This is good to know. Did you also unmap the lower identity mapping? We do not need the temporary lower map after we jump to high memory. We however keep the direct map for the physical RAM. > What changed: > > - c_boot_entry() runs at the physical alias, then > riscv64_jump_higher_half() rebases SP/sscratch and jumps to > c_boot_entry_high() — a separate function because the jump needs a > clean frame (the old one points at physical addresses). > Hmm, I need to check this part. In aarch64, Sergey applies a memory fence, reloads the stack variables with the new addresses, and continues through the same function. If we could keep the high address boot entry in the same function without splitting, I would prefer that instead. > - boot_intr_stack (16 KiB) is the interrupt stack published through > sscratch. RISC-V has no hardware stack switch on traps, so trap > entry will swap sp/sscratch and needs a valid kernel stack from the > first instruction. > > Before I turn this into patches, one question: does this match the > sscratch/kernel-stack contract you had in mind for the trap entry? My > assumption is that sscratch holds the interrupt stack top while running > on the kernel stack; a trap from userspace swaps sp/sscratch and stores > user regs into the thread's USER_REGS area; traps from kernel mode use > the current stack. If that is the intended scheme, I will rework the > trap entry on top of it. > Your idea about the interrupt stack seems reasonable, but I will need to check how other ports handle it first. Would you be able to provide the patch about high-address work first, before we commence with trap handling? I am relocating to another country currently, so I will be rather busy in the following weeks. I apologize for the delays caused by my part. Hakan > Thanks, > Diego
