On Fri, Jun 21, 2024 at 10:58:16AM -0700, Eric Biggers wrote: > 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... Right. I was thinking similarly, and that we should just disable all in-kernel vector code if the platform doesn't support misaligned vector.
Attachment:
signature.asc
Description: PGP signature
