On 23/01/2023 3:17 pm, Oleksii wrote: > On Mon, 2023-01-23 at 11:50 +0000, Andrew Cooper wrote: >> On 20/01/2023 2:59 pm, Oleksii Kurochko wrote: >>> + /* Save context to stack */ >>> + REG_S sp, (RISCV_CPU_USER_REGS_OFFSET(sp) - >>> RISCV_CPU_USER_REGS_SIZE) (sp) >>> + addi sp, sp, -RISCV_CPU_USER_REGS_SIZE >>> + REG_S t0, RISCV_CPU_USER_REGS_OFFSET(t0)(sp) >> Exceptions on RISC-V don't adjust the stack pointer. This logic >> depends >> on interrupting Xen code, and Xen not having suffered a stack >> overflow >> (and actually, that the space on the stack for all registers also >> doesn't overflow). >> >> Which might be fine for now, but I think it warrants a comment >> somewhere >> (probably at handle_exception itself) stating the expectations while >> it's still a work in progress. So in this case something like: >> >> /* Work-in-progress: Depends on interrupting Xen, and the stack >> being >> good. */ >> >> >> But, do we want to allocate stemp right away (even with an empty >> struct), and get tp set up properly? >> > I am not sure that I get you here about stemp. Could you please clarify > a little bit.
Sorry - sscratch, not stemp - I got the name wrong. All registers are the interrupted context, not Xen's context. This includes the stack pointer, global pointer, and thread pointer. Trap setup is supposed to stash Xen's tp in sscratch so on an interrupt/exception, it can exchange sscratch with tp and recover the stack pointer. Linux plays games with having sscratch be 0 while in kernel and uses this to determine whether the exception occurred in kernel or user mode. This is massive can of re-entrancy bugs that appears to be baked into the architecture. I genuinely can't figure out a safe way to cope with a stack overflow, or a bad tp, because it is not safe to a pagefault until the exception prologue has completed. If you do, you'll switch back to the interrupted task's tp and use that as if it were Xen's. ~Andrew
