Re: [PATCH v3 2/2] selftests/riscv: Add Zicbop prefetch test

[Andrew Jones <ajones@ventanamicro.com>]

On Thu, Oct 23, 2025 at 11:48:18PM +0800, Yao Zihong wrote:
> > Undesired reformatting
> My bad. It will be fixed in the next version.
> 
> > Should we just unconditionally register handlers for SIGSEGV and SIGBUS?
> I think it depends on what the flags --sig{segv,ill,bus} are intended to mean:
> 
>   a) We intend to handle these faults that might be raised inside the test
>      (i.e., catch and convert them into pass/fail results without crashing the
>      test binary, rather than letting something else handle them externally).
>   b) We expect these signals to be raised as part of the test scenario and
>      handle them within the test program accordingly.
> 
> I'm not sure if (a) is appropriate, since it might mess up someone’s CI
> or other automation setups.

The intention of --sigill is to tell the test that a SIGILL is expected
and tests should be run to ensure they are raised. We should probably
allow that expectation to be extension specific though, i.e. have both a
--zicbom-raises-sigill and a --zicboz-raises-sigill

> 
> If we’re going with (b), then registering handlers for SIGSEGV and SIGBUS
> based on flags would be inconsistent with that semantics, since prefetch.*
> should never legitimately raise them. In that case, this design probably
> doesn’t make sense. Would it also make sense to rename the '--sigill' flag
> to make this clearer?

Since SIGSEGV and SIGBUS are never expected, then we could always handle
those in order to report failures, but we should narrow the time the
handlers are registered to be just around the use of instructions under
test.

Thanks,
drew

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv