[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