| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CALs-HsuCu-C04vnGRV69S4TQx_URZGmKRbK+ekARR6ZM_SNVHg@mail.gmail.com>
Date: Wed, 26 Jun 2024 08:44:33 -0700
From: Evan Green <evan@...osinc.com>
To: Conor Dooley <conor@...nel.org>
Cc: Palmer Dabbelt <palmer@...belt.com>, Yangyu Chen <cyy@...self.name>,
Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alexghiti@...osinc.com>,
Andrew Jones <ajones@...tanamicro.com>, Andy Chiu <andy.chiu@...ive.com>,
Ben Dooks <ben.dooks@...ethink.co.uk>, Björn Töpel <bjorn@...osinc.com>,
Charlie Jenkins <charlie@...osinc.com>, Clément Léger <cleger@...osinc.com>,
Conor Dooley <conor.dooley@...rochip.com>, Costa Shulyupin <costa.shul@...hat.com>,
Erick Archer <erick.archer@....com>, "Gustavo A. R. Silva" <gustavoars@...nel.org>,
Jonathan Corbet <corbet@....net>, Paul Walmsley <paul.walmsley@...ive.com>, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v2 2/2] RISC-V: hwprobe: Add SCALAR to misaligned perf defines
On Wed, Jun 26, 2024 at 7:34 AM Conor Dooley <conor@...nel.org> wrote:
>
> On Tue, Jun 25, 2024 at 12:08:09PM -0700, Evan Green wrote:
> > On Tue, Jun 25, 2024 at 11:35 AM Conor Dooley <conor@...nel.org> 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@...osinc.com>
> > > >
> > > > ---
> > > >
> > > > 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.
>
> So apparently this isn't quite Palmer actually wanted. In today's call
> he suggested that he'd send a new version himself, but also that what we
> should do define a new key for scalar /and/ new add new defines values that
> contain the word scalar, retaining the old defines. The values can of
> course be the same.
Ahh, got it. I'm happy to spin this.
-Evan
Powered by blists - more mailing lists