On Fri, Jun 21, 2024 at 10:18:23AM -0700, Charlie Jenkins wrote: > > Additionally, what are we doing in the kernel if we detect that > > misaligned stuff isn't supported? Are we going to mandate that kernel > > code is aligned only, disable in-kernel vector or some other mechanism > > to make sure that things like crypto code don't have/introduce code > > that'll not run on these systems? > > UNSUPPORTED will still be set by the quick probe so it would be possible > for the kernel/userspace to avoid running misaligned vector when it's > unsupported. Any kernel methods would probably want to always run > aligned vector unless misaligned support was determined to be FAST > anyway, I am doubtful that code will have different optimizations for > FAST, SLOW, and UNSUPPORTED but it is possible. > > I would prefer consistency between scalar and vector misaligned support, > but this is not a deal breaker for this patch. I am not convinced it is > the best choice, but I am okay with leaving this option in the kernel. > Note that most of the vector crypto code (in arch/riscv/crypto/) assumes that vector misaligned accesses are supported. Many of the RISC-V vector crypto instructions require using SEW=32 or SEW=64, and as a result, loads and stores of data can be misaligned unless the code changes the SEW to 8 and back again, which would be inefficient and add extra complexity. I don't anticipate workarounds for CPUs that couldn't be bothered to support misaligned accesses being added. So what we'll probably have to do is just disable the vector crypto algorithms if the CPU doesn't support misaligned accesses... - Eric
