[PATCH] lib: sbi: Install the next-stage entry as a direct-mode xtvec

[Chen Pei]

Hi Nickolai,

Thanks for tracking this down.

I ran into the same problem a while ago, but fixed it from the Linux
side by aligning secondary_start_sbi to 4 bytes:

https://lore.kernel.org/linux-riscv/20260413132009.133752-1-cp0613@linux.alibaba.com/

With the C extension, a 2-byte aligned start_addr is a perfectly
legal input to sbi_hsm_hart_start(), so OpenSBI should not turn it
into a reserved xtvec mode. I support this fix, and I see it as
complementary to my kernel-side change rather than an alternative to
it: the firmware fix covers every next stage, while an aligned entry
simply makes the mask a no-op.

Tested on QEMU riscv64 virt (-smp 4) with a kernel whose
secondary_start_sbi is 2-byte aligned: before the patch, "-d unimp"
logs three "CSR_STVEC: reserved mode not supported" messages; with
the patch, none, and all 4 CPUs come up.

> sbi_hart_switch_mode() writes next_addr unmasked into stvec (vstvec,
> utvec).  Bits [1:0] of xtvec are the MODE field, so a 2-byte aligned
> entry, legal with the C extension, selects a reserved mode: QEMU drops
> the write, the Sail model keeps the old mode, and the next stage starts
> with a trap vector that is not its entry.
>
> Mask the mode bits and install the entry as a direct-mode vector; mepc
> still receives the exact address.
>
> Signed-off-by: Nickolai Zeldovich <nickolai.zeldovich at gmail.com>

Tested-by: Chen Pei <cp0613 at linux.alibaba.com>

Best regards,
Pei