linux-kernel - Re: [PATCH v12 04/17] riscv: Add vector feature to compile

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y3QP9zjM3a4yifvi@spud>
Date:   Tue, 15 Nov 2022 22:17:27 +0000
From:   Conor Dooley <conor@...nel.org>
To:     Vineet Gupta <vineetg@...osinc.com>
Cc:     Conor.Dooley@...rochip.com, bjorn@...nel.org,
        stillson@...osinc.com, greentime.hu@...ive.com,
        guoren@...ux.alibaba.com, vincent.chen@...ive.com,
        paul.walmsley@...ive.com, palmer@...belt.com,
        aou@...s.berkeley.edu, guoren@...nel.org,
        linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
        ajones@...tanamicro.com
Subject: Re: [PATCH v12 04/17] riscv: Add vector feature to compile

On Tue, Nov 15, 2022 at 09:38:53AM -0800, Vineet Gupta wrote:
> On 11/13/22 08:16, Conor.Dooley@...rochip.com wrote:
> > > > +config VECTOR
> > > > +     bool "VECTOR support"
> > > > +     depends on GCC_VERSION >= 120000 || CLANG_VERSION >= 130000
> > > > +     default n
> > > > +     help
> > > > +       Say N here if you want to disable all vector related procedure
> > > > +       in the kernel.
> > > > +
> > > > +       If you don't know what to do here, say Y.
> > > > +
> > > > +endmenu
> > > "VECTOR" is not really consistent to how the other configs are named;
> > > RISCV_ISA_V, RISCV_ISA_VECTOR, RISCV_VECTOR?
> > It'd be RISCV_ISA_V to match the others single letter extentions, right?
> 
> Yep.
> 
> > The toolchain dependency check here also seems rather naive.
> 
> Indeed. I can build the code just fine with gcc-11 (and gcc-12), although my
> reworked patcheset doesn't include all the orig patches including the
> in-kernel xor stuff.

By naive here I meant that checking cc alone is probably not a
sufficient check for whether the toolchain supports the extension.
What about the assembler etc?

With Zicbom and Zihintpause we ran into problems with mixed usage, eg
binutils 2.35 + gcc 12. In his Zicboz series Drew has gone with insn
definitions - but while that's okay for something small like Zicboz,
do we want to do that for something with as many instructions as vector?

The alternative is cc-option, but that feels a lot less clean than what
Drew cooked up here:
https://lore.kernel.org/linux-riscv/20221027130247.31634-1-ajones@ventanamicro.com/

I've not checked this because I am lazy, but I am also assuming that
whoever put clang-13 in there picked it such that it doesn't require
experimental extensions flags. Mostly just writing this to remind myself
to check it at some point.