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

[ Anup, Bo, OpenSBI list: It's the already reported issue where
SBI_PLATFORM_DEFAULT_HART_STACK_SIZE is not enough for
sbi_misaligned_v_ld_emulator. How should we approach this? ]

On 5/21/26 19:49, Michael Ellerman wrote:
> 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.
>
Thanks for confirming. I've already told Greg to drop the stable
backport [2]. I still think that's the right thing to do - users on
older stable kernels don't need to get surprised by this.

> 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.

Yes, thanks. That's the one I had in mind but forgot the exact location of.

>
> 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?
>
Allocation on boot would probably be better. Or maybe there's some way
to refactor it to not use so much stack.

> Or just force the stack to be bigger when vector is enabled, eg:
>
> [...]

Possibly. I'm not sure. "CC_SUPPORTS" sounds wrong.

I haven't dealt with OpenSBI for a good while so I don't have much of an
idea about what should be done here. Bo Gan's thread on the OpenSBI list
[1] is probably a better place to talk about this. Or maybe we should
send a patch to bump the stack size first and try to deal with it later. 

Vivian "dramforever" Wang

[1]:
https://lore.kernel.org/opensbi/[email protected]/
[2]:
https://lore.kernel.org/stable/[email protected]/


-- 
opensbi mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/opensbi