Re: [PATCH v2 1/2] RISC-V: hwprobe: Add MISALIGNED_PERF key

[Conor Dooley <conor@kernel.org>]

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

On Tue, Jun 25, 2024 at 09:51:20AM -0700, Evan Green wrote:
> RISCV_HWPROBE_KEY_CPUPERF_0 was mistakenly flagged as a bitmask in
> hwprobe_key_is_bitmask(), when in reality it was an enum value. This
> causes problems when used in conjunction with RISCV_HWPROBE_WHICH_CPUS,
> since SLOW, FAST, and EMULATED have values whose bits overlap with
> each other. If the caller asked for the set of CPUs that was SLOW or
> EMULATED, the returned set would also include CPUs that were FAST.
> 
> Introduce a new hwprobe key, RISCV_HWPROBE_KEY_MISALIGNED_PERF, which
> returns the same values in response to a direct query (with no flags),
> but is properly handled as an enumerated value. As a result, SLOW,
> FAST, and EMULATED are all correctly treated as distinct values under
> the new key when queried with the WHICH_CPUS flag.
> 
> Leave the old key in place to avoid disturbing applications which may
> have already come to rely on the key, with or without its broken
> behavior with respect to the WHICH_CPUS flag.
> 
> Fixes: e178bf146e4b ("RISC-V: hwprobe: Introduce which-cpus flag")
> Signed-off-by: Evan Green <evan@rivosinc.com>
> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
> Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
> 
> ---
> 
> Changes in v2:
>  - Clarified the distinction of slow and fast refers to misaligned word
>    accesses. Previously it just said misaligned accesses, leaving it
>    ambiguous as to which type of access was measured.

I think if we are gonna be specific, we should be exactly specific as to
what we have tested and say 32-bit if that's what we're probing/testing
with. That'd be consistent with jesse's proposed wording for vector.

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