Re: [PATCH v5 2/2] riscv: Set unaligned access speed at compile time

[Conor Dooley <conor.dooley@microchip.com>]

[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]

On Thu, Feb 29, 2024 at 11:23:08AM -0800, Charlie Jenkins wrote:
> > > > 1 probe: probe at boot time, falling back to emulated if not performant
> > > > 2 emulated: always emulate it in the kernel
> > > > 3 slow: don't probe or emulate in the kernel
> > > > 4 fast: Your current fast option
> > > 
> > > Emulated doesn't mean that the kernel will always emulate the unaligned
> > > accesses. It means that the kernel has the ability to emulate them. It
> > > will only emulate them if the CPU traps on unaligned accesses. Kernel
> > > code can choose to forcefully align an address it thinks may cause an
> > > unaligned access, but that's slightly different from emulated.
> > 
> > Sure, make option 2 "don't probe at boot time, emulate it in the kernel
> > if we trap". I suppose in this case though, to get a correct output in
> > hwprobe you'd have to still attempt an unaligned access at boot time to
> > see if you trap but it will not perform the speed test?
> 
> Are you trying to cover the case here that the kernel is compiled as
> "emulate unaligned accesses" but the kernel isn't actually needed to
> emulate unaligned accesses?

Nope, the case "don't probe at boot time, emulate it in the kernel if
we trap" which is replacing 2 above.

> Seems like if the kernel is compiled as
> such it would make sense to report emulated with the assumption that if
> the kernel isn't emulating it, something else is.

Or maybe nothing is emulating it, we don't know. Feels to me like it
should report slow by default, given that's the option you can infer the
least information from, and then report emulated on trap.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]