STVEC and handling kernel interrupts/exceptions

I am trying to use the standard u-boot-spl -> opensbi -> u-boot -> kernel pipeline to boot my kernel, which works fine. Thus my kernel starts in S-mode as I would expect. However I would like to handle hardware interrupts at S-mode in my kernel, as well as U-mode syscalls. Can I slot my handler into stvec? Register dumps tell me that it is currently set to some 0xfff_____ value, which I believe is set during the u-boot-spl stage of booting. If it is not safe to overwrite the CSR, what is the intended way of handling interrupts and exceptions? My reading of the privileged spec is that a U-mode ecall should be handled first by the S-mode handler, so that would not be worry, but it is not clear to me that if I overwrite stvec, would any S-mode attempted sbi calls be handled by mtvec (what I presume to be the opensbi handler), or would they go first to the stvec handler?

There is also some hints in the opensbi codebase and elsewhere that delegation is performed by handling first in M-mode and then passing down as necessary. In this case how are kernel sbi calls differentiated from syscalls intended for the kernel?

I have not found any other issues here about how this works, nor did I find answers in the opensbi code or the low level riscv parts of the linux source. Please advise.

Start with the RISC-V privileged specification sections on stvec, mtvec, traps, delegation, and ecall handling. Then inspect the OpenSBI codebase and the low-level RISC-V parts of the Linux source mentioned in the issue, tracing the u-boot-spl → OpenSBI → u-boot → kernel path. Done means documenting how S-mode handlers, M-mode handlers, SBI calls, and U-mode syscalls are distinguished.