linux-kernel - [PATCH 0/2] RISC-V: Probe for misaligned access speed

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 23 Jun 2023 15:20:14 -0700
From:   Evan Green <evan@...osinc.com>
To:     Palmer Dabbelt <palmer@...osinc.com>
Cc:     Simon Hosie <shosie@...osinc.com>, Evan Green <evan@...osinc.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Alexandre Ghiti <alexghiti@...osinc.com>,
        Andrew Jones <ajones@...tanamicro.com>,
        Andy Chiu <andy.chiu@...ive.com>,
        Anup Patel <apatel@...tanamicro.com>,
        Conor Dooley <conor.dooley@...rochip.com>,
        Greentime Hu <greentime.hu@...ive.com>,
        Guo Ren <guoren@...nel.org>,
        Heiko Stuebner <heiko.stuebner@...ll.eu>,
        Heiko Stuebner <heiko@...ech.de>,
        Jisheng Zhang <jszhang@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Ley Foon Tan <leyfoon.tan@...rfivetech.com>,
        Li Zhengyu <lizhengyu3@...wei.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Samuel Holland <samuel@...lland.org>,
        Sia Jee Heng <jeeheng.sia@...rfivetech.com>,
        Sunil V L <sunilvl@...tanamicro.com>,
        Xianting Tian <xianting.tian@...ux.alibaba.com>,
        Yangyu Chen <cyy@...self.name>, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: [PATCH 0/2] RISC-V: Probe for misaligned access speed

The current setting for the hwprobe bit indicating misaligned access
speed is controlled by a vendor-specific feature probe function. This is
essentially a per-SoC table we have to maintain on behalf of each vendor
going forward. Let's convert that instead to something we detect at
runtime.

We have two assembly routines at the heart of our probe: one that
does a bunch of word-sized accesses (without aligning its input buffer),
and the other that does byte accesses. If we can move a larger number of
bytes using misaligned word accesses than we can with the same amount of
time doing byte accesses, then we can declare misaligned accesses as
"fast".

The tradeoff of reducing this maintenance burden is boot time. We spend
4-6 jiffies per core doing this measurement (0-2 on jiffie edge
alignment, and 4 on measurement). The timing loop was based on
raid6_choose_gen(), which uses (16+1)*N jiffies (where N is the number
of algorithms). On my THead C906, I found measurements to be stable
across several reboots, and looked like this:

[    0.047582] cpu0: Unaligned word copy 1728 MB/s, byte copy 402 MB/s, misaligned accesses are fast

I don't have a machine where misaligned accesses are slow, but I'd be
interested to see the results of booting this series if someone did.

Evan Green (2):
  RISC-V: Probe for unaligned access speed
  RISC-V: alternative: Remove feature_probe_func

 Documentation/riscv/hwprobe.rst      |  8 +--
 arch/riscv/errata/thead/errata.c     |  8 ---
 arch/riscv/include/asm/alternative.h |  5 --
 arch/riscv/include/asm/cpufeature.h  |  2 +
 arch/riscv/kernel/Makefile           |  1 +
 arch/riscv/kernel/alternative.c      | 19 -------
 arch/riscv/kernel/copy-noalign.S     | 71 +++++++++++++++++++++++++
 arch/riscv/kernel/copy-noalign.h     | 13 +++++
 arch/riscv/kernel/cpufeature.c       | 78 ++++++++++++++++++++++++++++
 arch/riscv/kernel/smpboot.c          |  3 +-
 10 files changed, 171 insertions(+), 37 deletions(-)
 create mode 100644 arch/riscv/kernel/copy-noalign.S
 create mode 100644 arch/riscv/kernel/copy-noalign.h

-- 
2.34.1