On Tue, Jun 25, 2024 at 11:35 AM Conor Dooley <conor@xxxxxxxxxx> wrote:
>
> On Tue, Jun 25, 2024 at 09:51:21AM -0700, Evan Green wrote:
> > In preparation for misaligned vector performance hwprobe keys, rename
> > the hwprobe key values associated with misaligned scalar accesses to
> > include the term SCALAR.
> >
> > Signed-off-by: Evan Green <evan@xxxxxxxxxxxx>
> >
> > ---
> >
> > Changes in v2:
> > - Added patch to rename misaligned perf key values (Palmer)
> >
> > Documentation/arch/riscv/hwprobe.rst | 20 ++++++++++----------
> > arch/riscv/include/uapi/asm/hwprobe.h | 10 +++++-----
> > arch/riscv/kernel/sys_hwprobe.c | 10 +++++-----
> > arch/riscv/kernel/traps_misaligned.c | 6 +++---
> > arch/riscv/kernel/unaligned_access_speed.c | 12 ++++++------
> > 5 files changed, 29 insertions(+), 29 deletions(-)
> >
> > diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
> > index c9f570b1ab60..83f7f3c1347f 100644
> > --- a/Documentation/arch/riscv/hwprobe.rst
> > +++ b/Documentation/arch/riscv/hwprobe.rst
> > @@ -215,22 +215,22 @@ The following keys are defined:
> > the performance of misaligned scalar word accesses on the selected set of
> > processors.
> >
> > - * :c:macro:`RISCV_HWPROBE_MISALIGNED_UNKNOWN`: The performance of misaligned
> > - accesses is unknown.
> > + * :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_UNKNOWN`: The performance of
> > + misaligned accesses is unknown.
> >
> > - * :c:macro:`RISCV_HWPROBE_MISALIGNED_EMULATED`: Misaligned accesses are
> > + * :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_EMULATED`: Misaligned accesses are
> > emulated via software, either in or below the kernel. These accesses are
> > always extremely slow.
> >
> > - * :c:macro:`RISCV_HWPROBE_MISALIGNED_SLOW`: Misaligned word accesses are
> > - slower than equivalent byte accesses. Misaligned accesses may be supported
> > - directly in hardware, or trapped and emulated by software.
> > + * :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_SLOW`: Misaligned word accesses
> > + are slower than equivalent byte accesses. Misaligned accesses may be
> > + supported directly in hardware, or trapped and emulated by software.
> >
> > - * :c:macro:`RISCV_HWPROBE_MISALIGNED_FAST`: Misaligned word accesses are
> > - faster than equivalent byte accesses.
> > + * :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_FAST`: Misaligned word accesses
> > + are faster than equivalent byte accesses.
> >
> > - * :c:macro:`RISCV_HWPROBE_MISALIGNED_UNSUPPORTED`: Misaligned accesses are
> > - not supported at all and will generate a misaligned address fault.
> > + * :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_UNSUPPORTED`: Misaligned accesses
> > + are not supported at all and will generate a misaligned address fault.
> >
> > * :c:macro:`RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`: An unsigned int which
> > represents the size of the Zicboz block in bytes.
> > diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
> > index 22073533cea8..e11684d8ae1c 100644
> > --- a/arch/riscv/include/uapi/asm/hwprobe.h
> > +++ b/arch/riscv/include/uapi/asm/hwprobe.h
> > @@ -66,11 +66,11 @@ struct riscv_hwprobe {
> > #define RISCV_HWPROBE_EXT_ZVE64F (1ULL << 40)
> > #define RISCV_HWPROBE_EXT_ZVE64D (1ULL << 41)
> > #define RISCV_HWPROBE_KEY_CPUPERF_0 5
> > -#define RISCV_HWPROBE_MISALIGNED_UNKNOWN 0
> > -#define RISCV_HWPROBE_MISALIGNED_EMULATED 1
> > -#define RISCV_HWPROBE_MISALIGNED_SLOW 2
> > -#define RISCV_HWPROBE_MISALIGNED_FAST 3
> > -#define RISCV_HWPROBE_MISALIGNED_UNSUPPORTED 4
> > +#define RISCV_HWPROBE_MISALIGNED_SCALAR_UNKNOWN 0
> > +#define RISCV_HWPROBE_MISALIGNED_SCALAR_EMULATED 1
> > +#define RISCV_HWPROBE_MISALIGNED_SCALAR_SLOW 2
> > +#define RISCV_HWPROBE_MISALIGNED_SCALAR_FAST 3
> > +#define RISCV_HWPROBE_MISALIGNED_SCALAR_UNSUPPORTED 4
> > #define RISCV_HWPROBE_MISALIGNED_MASK 7
>
> How come the "old" names do not need to be preserved for userspace?
It depends on what exactly the big userspace compatibility rule is.
This preserves binary compatibility, which I think is the big one, but
breaks source compatibility, though with an easy translation to fix.
We could keep the old names around, but then it seems sort of silly to
introduce the new names. I introduced this patch upon request, so I
don't personally have a horse in the race on this one.
-Evan
