Re: [PATCH v2] riscv: misaligned: Make enabling delegation depend on NONPORTABLE

[Michael Ellerman]

On 21/5/2026 10:27, Vivian Wang wrote:
> On 5/20/26 23:47, Anirudh Srinivasan wrote:
> > Hi Vivian, Paul
> >
> > On Wed, Apr 01, 2026 at 09:53:17AM +0800, Vivian Wang wrote:
> > > The unaligned access emulation code in Linux has various deficiencies.
> > > For example, it doesn't emulate vector instructions [1] [2], and doesn't
> > > emulate KVM guest accesses. Therefore, requesting misaligned exception
> > > delegation with SBI FWFT actually regresses vector instructions' and KVM
> > > guests' behavior.
> > >
> > > Until Linux can handle it properly, guard these sbi_fwft_set() calls
> > > behind RISCV_SBI_FWFT_DELEGATE_MISALIGNED, which in turn depends on
> > > NONPORTABLE. Those who are sure that this wouldn't be a problem can
> > > enable this option, perhaps getting better performance.
> > >
> > > The rest of the existing code proceeds as before, except as if
> > > SBI_FWFT_MISALIGNED_EXC_DELEG is not available, to handle any remaining
> > > address misaligned exceptions on a best-effort basis. The KVM SBI FWFT
> > > implementation is also not touched, but it is disabled if the firmware
> > > emulates unaligned accesses.
> > On a Tenstorrent Blackhole with SiFive x280 cores, with OpenSBI 1.7 and
> > defconfig kernel, I'm seeing a bunch of hangs/opensbi prints at boot time.
> > Without this patch, the boot prints this and continues on.
> >
> > [    0.226339] SBI misaligned access exception delegation ok
>
> Your OpenSBI looks very broken (more on what I mean later), and in a way
> that might only manifest if it's trying to emulate vector misaligned
> instructions? An interesting thing I can think of is maybe your SiFive
> x280 has a very long VLEN (512? 1024? I forgot) which may have exposed
> some stuff...

It's 512.

> I have two ideas:
>
> Firstly, try bumping this in include/sbi/sbi_platform.h up to 65536 or
> something like that. If that works you can also start trying to lower it
> to 16384 or something similar.
>
> #define SBI_PLATFORM_DEFAULT_HART_STACK_SIZE    8192

Yep, bumping that to 16384 fixes it for me.

The culprit is in lib/sbi/sbi_trap_v_ldst.c:

#define VLEN_MAX 65536
...

int sbi_misaligned_v_ld_emulator(int rlen, union sbi_ldst_data *out_val,
                                 struct sbi_trap_context *tcntx)
{
        const struct sbi_trap_info *orig_trap = &tcntx->trap;
...
        uint8_t mask[VLEN_MAX / 8];


ie. 8KB on stack buffer.

Shrinking VLEN_MAX to 4096 also gets it booting. But I guess that's not 
viable because in theory someone might build a chip with VLEN 65536 one day?

Would a heap allocation at boot be better?

Or just force the stack to be bigger when vector is enabled, eg:

diff --git a/include/sbi/sbi_platform.h b/include/sbi/sbi_platform.h
index fe382b56..52ed48af 100644
--- a/include/sbi/sbi_platform.h
+++ b/include/sbi/sbi_platform.h
@@ -160,7 +160,11 @@ struct sbi_platform_operations {
 };

 /** Platform default per-HART stack size for exception/interrupt 
handling */
+#ifdef OPENSBI_CC_SUPPORT_VECTOR
+#define SBI_PLATFORM_DEFAULT_HART_STACK_SIZE   16384
+#else
 #define SBI_PLATFORM_DEFAULT_HART_STACK_SIZE   8192
+#endif

 /** Platform default heap size */
 #define SBI_PLATFORM_DEFAULT_HEAP_SIZE(__num_hart)     \

cheers