From: Eric Biggers <ebiggers@kernel.org>
To: Conor Dooley <conor@kernel.org>
Cc: "Conor Dooley" <conor.dooley@microchip.com>,
"Andy Chiu" <andy.chiu@sifive.com>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Heiko Stuebner" <heiko@sntech.de>, "Guo Ren" <guoren@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Jonathan Corbet" <corbet@lwn.net>,
"Evan Green" <evan@rivosinc.com>,
"Clément Léger" <cleger@rivosinc.com>,
"Shuah Khan" <shuah@kernel.org>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
"Palmer Dabbelt" <palmer@rivosinc.com>,
"Vincent Chen" <vincent.chen@sifive.com>,
"Greentime Hu" <greentime.hu@sifive.com>,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kselftest@vger.kernel.org,
"Joel Granados" <j.granados@samsung.com>,
"Jerry Shih" <jerry.shih@sifive.com>
Subject: Re: [PATCH v4 7/9] riscv: vector: adjust minimum Vector requirement to ZVE32X
Date: Thu, 18 Apr 2024 11:41:29 -0700 [thread overview]
Message-ID: <20240418184129.GA1071@sol.localdomain> (raw)
In-Reply-To: <20240418-sterling-sanding-d59c3b0a2aaa@spud>
On Thu, Apr 18, 2024 at 07:26:00PM +0100, Conor Dooley wrote:
> That's great if it does require that the version of the vector extension
> must be standard. Higher quality spec than most if it does. But
> "supported" in the context of riscv_isa_extension_available() means that
> the hardware supports it (or set of harts), not that the currently
> running kernel does. The Kconfig deps that must be met for the code to be
> built at least mean the kernel is built with vector support, leaving only
> "the kernel was built with vector support and the hardware supports vector
> but for $reason the kernel refused to enable it".
>
> I'm not sure if that final condition is actually possible with the system
> ending up in a broken state, however - I'm not sure that we ever do turn
> off access to the VPU at present (after we mark it usable), and if we do
> it doesn't get reflected in has_vector() so the kernel and userspace would
> both break, with what a crypto driver does probably being the least of
> your worries.
>
> > I am just concerned about how you're suggesting that non-standard extensions
> > might be pretending to be standard ones and individual users of kernel-mode
> > vector would need to work around that.
>
> I am absolutely not suggesting that non-standard extensions should
> masquerade as standard ones, I don't know where you got that from. What
> I said was that a non-standard vector extension could reuse riscv_v_vlen
> (and should IMO for simplicity reasons), not that any of the APIs we have
> for checking extension availability would lie and say it was standard.
> riscv_v_vlen having a value greater than 128 is not one of those APIs ;)
It sounded like you were suggesting that a CPU could plausibly have a
pre-standard version of the vector extension but also have standard Zvkb. I
don't think this makes sense, due to the dependency.
> > I think that neither has_vector() nor
> > 'if (riscv_isa_extension_available(NULL, ZVKB))' should return true if the CPU's
> > vector extension is non-standard.
>
> riscv_isa_extension_available(NULL, ZVKB) only checks whether the extension
> was present in DT or ACPI for all harts. It doesn't check whether or not
> the required config option for vector has been set or anything related
> to dependencies. has_vector() at least checks that the vector core has
> been enabled (and uses the alternative-patched version of the check
> given it is used in some hotter paths). That's kinda moot for code
> that's only built if the vector core stuff is enabled as I said above
> though.
>
> We could of course make riscv_isa_extension_available() check
> extension dependencies, but I'd rather leave dt validation to the dt
> tooling (apparently ACPI tables are never wrong...). Either would allow
> you to rely on the crypto extensions present only when the standard vector
> extensions unless someone's DT/ACPI stuff is shite, but then they keep the
> pieces IMO :)
>
> Hope that makes sense?
If the RISC-V kernel ever disables V, then it should also disable everything
that depends on V.
This would be similar to how on x86, if the kernel decides to disable AVX to
mitigate the Gather Data Sampling vulnerability, it also disables AVX2, AVX512,
VAES, VPCLMULQDQ, etc. See cpuid_deps[] in arch/x86/kernel/cpu/cpuid-deps.c.
Sometimes CPU features depend on other ones. That's just the way things work.
Whenever possible that should be handled centrally, not pushed down to every
user both in-kernel and userspace.
- Eric
next prev parent reply other threads:[~2024-04-18 18:41 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-12 6:48 [PATCH v4 0/9] Support Zve32[xf] and Zve64[xfd] Vector subextensions Andy Chiu
2024-04-12 6:48 ` [PATCH v4 1/9] riscv: vector: add a comment when calling riscv_setup_vsize() Andy Chiu
2024-04-18 9:54 ` Conor Dooley
2024-04-12 6:48 ` [PATCH v4 2/9] riscv: smp: fail booting up smp if inconsistent vlen is detected Andy Chiu
2024-04-18 10:17 ` Conor Dooley
2024-04-19 6:09 ` [External] " yunhui cui
2024-04-24 20:01 ` Alexandre Ghiti
2024-05-08 8:21 ` Andy Chiu
2024-05-08 10:43 ` Alexandre Ghiti
2024-04-12 6:48 ` [PATCH v4 3/9] riscv: cpufeature: call match_isa_ext() for single-letter extensions Andy Chiu
2024-04-18 10:29 ` Conor Dooley
2024-04-12 6:49 ` [PATCH v4 4/9] riscv: cpufeature: add zve32[xf] and zve64[xfd] isa detection Andy Chiu
2024-04-18 10:19 ` Conor Dooley
2024-04-12 6:49 ` [PATCH v4 5/9] dt-bindings: riscv: add Zve32[xf] Zve64[xfd] ISA extension description Andy Chiu
2024-04-18 10:21 ` Conor Dooley
2024-04-12 6:49 ` [PATCH v4 6/9] riscv: hwprobe: add zve Vector subextensions into hwprobe interface Andy Chiu
2024-04-12 6:49 ` [PATCH v4 7/9] riscv: vector: adjust minimum Vector requirement to ZVE32X Andy Chiu
2024-04-18 11:02 ` Conor Dooley
2024-04-18 15:52 ` Eric Biggers
2024-04-18 16:53 ` Conor Dooley
2024-04-18 17:32 ` Eric Biggers
2024-04-18 17:39 ` Eric Biggers
2024-04-18 18:26 ` Conor Dooley
2024-04-18 18:28 ` Conor Dooley
2024-04-18 18:41 ` Eric Biggers [this message]
2024-04-18 20:00 ` Conor Dooley
2024-05-09 6:56 ` Andy Chiu
2024-05-09 7:48 ` Conor Dooley
2024-05-09 8:25 ` Conor Dooley
2024-05-09 22:22 ` Conor Dooley
2024-04-12 6:49 ` [PATCH v4 8/9] hwprobe: fix integer promotion in RISCV_HWPROBE_EXT macro Andy Chiu
2024-04-12 6:49 ` [PATCH v4 9/9] selftest: run vector prctl test for ZVE32X Andy Chiu
2024-04-25 23:00 ` [PATCH v4 0/9] Support Zve32[xf] and Zve64[xfd] Vector subextensions patchwork-bot+linux-riscv
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240418184129.GA1071@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=andy.chiu@sifive.com \
--cc=aou@eecs.berkeley.edu \
--cc=cleger@rivosinc.com \
--cc=conor.dooley@microchip.com \
--cc=conor@kernel.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=evan@rivosinc.com \
--cc=greentime.hu@sifive.com \
--cc=guoren@kernel.org \
--cc=heiko@sntech.de \
--cc=j.granados@samsung.com \
--cc=jerry.shih@sifive.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=palmer@rivosinc.com \
--cc=paul.walmsley@sifive.com \
--cc=robh@kernel.org \
--cc=shuah@kernel.org \
--cc=vincent.chen@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).