diff mbox series

[v3,2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto

Message ID YqY0i22SdbHjB/MX@Sun (mailing list archive)
State New
Headers show
Series RISC-V: Add Bitmanip/Scalar Crypto HWCAP | expand

Commit Message

Hongren Zheng June 12, 2022, 6:46 p.m. UTC 
userspace currently lacks a way to detect whether the
platform has Bitmanip/Scalar Crypto capability,
this patch adds an interface such that the userspace
can detect it.

RISC-V currently still has no mature mechanism,
but no matter how things in the spec changes,
(no matter how "M" mode things change), the kernel
still needs to offer some API to the userspace.

More discussion can be found at
https://github.com/openssl/openssl/pull/18197
In short, userspace currently has to use env var
to detect them.

This interface does not make any assumptions about the
underlying hardware

Tested-by: Jiatai He <jiatai2021@iscas.ac.cn>
Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me>
---
 arch/riscv/include/uapi/asm/hwcap.h | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

Comments

Samuel Ortiz Nov. 24, 2022, 9:30 a.m. UTC | #1 
On Mon, Jun 13, 2022 at 02:46:35AM +0800, Hongren (Zenithal) Zheng wrote:
> diff --git a/arch/riscv/include/uapi/asm/hwcap.h b/arch/riscv/include/uapi/asm/hwcap.h
> index 46dc3f5ee99f..bfed3e5c338c 100644
> --- a/arch/riscv/include/uapi/asm/hwcap.h
> +++ b/arch/riscv/include/uapi/asm/hwcap.h
> @@ -22,4 +22,26 @@
>  #define COMPAT_HWCAP_ISA_D	(1 << ('D' - 'A'))
>  #define COMPAT_HWCAP_ISA_C	(1 << ('C' - 'A'))
>  
> +/*
> + * HWCAP2 flags - for elf_hwcap2 (in kernel) and AT_HWCAP2
> + *
> + * As only 32 bits of elf_hwcap (in kernel) could be used
> + * and RISC-V has reserved 26 bits of it, other caps like
> + * bitmanip and crypto can not be placed in AT_HWCAP
> + */

Have we agreed that multi-letter ISA extensions would use hwcap to be
exposed to userspace? With so many potential extensions, we could
quickly run out of space on AT_HWCAP2 as well.

Cheers,
Samuel.
Conor Dooley Nov. 24, 2022, 9:58 a.m. UTC | #2 
On Thu, Nov 24, 2022 at 10:30:21AM +0100, Samuel Ortiz wrote:
> On Mon, Jun 13, 2022 at 02:46:35AM +0800, Hongren (Zenithal) Zheng wrote:
> > diff --git a/arch/riscv/include/uapi/asm/hwcap.h b/arch/riscv/include/uapi/asm/hwcap.h
> > index 46dc3f5ee99f..bfed3e5c338c 100644
> > --- a/arch/riscv/include/uapi/asm/hwcap.h
> > +++ b/arch/riscv/include/uapi/asm/hwcap.h
> > @@ -22,4 +22,26 @@
> >  #define COMPAT_HWCAP_ISA_D	(1 << ('D' - 'A'))
> >  #define COMPAT_HWCAP_ISA_C	(1 << ('C' - 'A'))
> >  
> > +/*
> > + * HWCAP2 flags - for elf_hwcap2 (in kernel) and AT_HWCAP2
> > + *
> > + * As only 32 bits of elf_hwcap (in kernel) could be used
> > + * and RISC-V has reserved 26 bits of it, other caps like
> > + * bitmanip and crypto can not be placed in AT_HWCAP
> > + */
> 
> Have we agreed that multi-letter ISA extensions would use hwcap to be
> exposed to userspace? With so many potential extensions, we could
> quickly run out of space on AT_HWCAP2 as well.

Palmer whipped up a PoC hwprobe interface (during Plumbers I think) that
Heiko is currently looking into - I think his motivation is misaligned
access performance. There's a branch but I have no idea if it even
compiles... I'm mostly waiting for whatever Heiko comes up with ;)

https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/log/?h=riscv-hwprobe-v1

This patchset seems to need a rebase anyway per your other reply, but I
guess that the new proposed interface would be preferable?

Thanks,
Conor.
Samuel Ortiz Nov. 24, 2022, 10:47 a.m. UTC | #3 
On Thu, Nov 24, 2022 at 09:58:53AM +0000, Conor Dooley wrote:
> On Thu, Nov 24, 2022 at 10:30:21AM +0100, Samuel Ortiz wrote:
> > On Mon, Jun 13, 2022 at 02:46:35AM +0800, Hongren (Zenithal) Zheng wrote:
> > > diff --git a/arch/riscv/include/uapi/asm/hwcap.h b/arch/riscv/include/uapi/asm/hwcap.h
> > > index 46dc3f5ee99f..bfed3e5c338c 100644
> > > --- a/arch/riscv/include/uapi/asm/hwcap.h
> > > +++ b/arch/riscv/include/uapi/asm/hwcap.h
> > > @@ -22,4 +22,26 @@
> > >  #define COMPAT_HWCAP_ISA_D	(1 << ('D' - 'A'))
> > >  #define COMPAT_HWCAP_ISA_C	(1 << ('C' - 'A'))
> > >  
> > > +/*
> > > + * HWCAP2 flags - for elf_hwcap2 (in kernel) and AT_HWCAP2
> > > + *
> > > + * As only 32 bits of elf_hwcap (in kernel) could be used
> > > + * and RISC-V has reserved 26 bits of it, other caps like
> > > + * bitmanip and crypto can not be placed in AT_HWCAP
> > > + */
> > 
> > Have we agreed that multi-letter ISA extensions would use hwcap to be
> > exposed to userspace? With so many potential extensions, we could
> > quickly run out of space on AT_HWCAP2 as well.
> 
> Palmer whipped up a PoC hwprobe interface (during Plumbers I think) that
> Heiko is currently looking into - I think his motivation is misaligned
> access performance. There's a branch but I have no idea if it even
> compiles... I'm mostly waiting for whatever Heiko comes up with ;)
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/log/?h=riscv-hwprobe-v1
> 
> This patchset seems to need a rebase anyway per your other reply, but I
> guess that the new proposed interface would be preferable?
I think so, yes.
Patch #1 is definitely needed regardless of which interface we pick for
exposing the ISA strings to userspace.

Cheers,
Samuel.
Conor Dooley Nov. 24, 2022, 11:55 a.m. UTC | #4 
On Thu, Nov 24, 2022 at 11:47:30AM +0100, Samuel Ortiz wrote:

> Patch #1 is definitely needed regardless of which interface we pick for
> exposing the ISA strings to userspace.

I took another look at #1, and I feel more confused about what
constitutes canonical order than I did before! If you know better than
I, and you probably do since you're interested in these 6 month old
patches, some insight would be appreciated!

Thanks,
Conor.
Samuel Ortiz Nov. 24, 2022, 5:12 p.m. UTC | #5 
On Thu, Nov 24, 2022 at 11:55:01AM +0000, Conor Dooley wrote:
> On Thu, Nov 24, 2022 at 11:47:30AM +0100, Samuel Ortiz wrote:
> 
> > Patch #1 is definitely needed regardless of which interface we pick for
> > exposing the ISA strings to userspace.
> 
> I took another look at #1, and I feel more confused about what
> constitutes canonical order than I did before! If you know better than
> I, and you probably do since you're interested in these 6 month old
> patches, some insight would be appreciated!

Assuming we don't go with hwcap, I dont think the order of the
riscv_isa_ext_id enum matters that much?

iiuc we're building the cpuinfo string from the riscv_isa_ext_data
array, and I think the current code is incorrect:

static struct riscv_isa_ext_data isa_ext_arr[] = {
    __RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF),
    __RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC),
    __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL),
    __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT),
    __RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM),
    __RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
    __RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX),
};

zicbom and zihintpause should come before supervisor level extensions.
I'm going to send a patch for that.

And the Zb/Zk ones should come after the Zi ones, and before the
supervisor level ones (The I category comes before the B or the K one).
So we should check that when patch #1 is rebased.

Cheers,
Samuel.
Conor Dooley Nov. 24, 2022, 5:20 p.m. UTC | #6 
On 24/11/2022 17:12, Samuel Ortiz wrote:
> [You don't often get email from sameo@rivosinc.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Thu, Nov 24, 2022 at 11:55:01AM +0000, Conor Dooley wrote:
>> On Thu, Nov 24, 2022 at 11:47:30AM +0100, Samuel Ortiz wrote:
>>
>>> Patch #1 is definitely needed regardless of which interface we pick for
>>> exposing the ISA strings to userspace.
>>
>> I took another look at #1, and I feel more confused about what
>> constitutes canonical order than I did before! If you know better than
>> I, and you probably do since you're interested in these 6 month old
>> patches, some insight would be appreciated!
> 
> Assuming we don't go with hwcap, I dont think the order of the
> riscv_isa_ext_id enum matters that much?

The chief put it in canonical order so that's good enough for me!

> 
> iiuc we're building the cpuinfo string from the riscv_isa_ext_data
> array, and I think the current code is incorrect:
> 
> static struct riscv_isa_ext_data isa_ext_arr[] = {
>     __RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF),
>     __RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC),
>     __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL),
>     __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT),
>     __RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM),
>     __RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
>     __RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX),
> };
> 
> zicbom and zihintpause should come before supervisor level extensions.
> I'm going to send a patch for that.

idk, Palmer explicitly re-ordered this:
https://lore.kernel.org/linux-riscv/20220920204518.10988-1-palmer@rivosinc.com/

By my reading of the isa manual, what Palmer did is correct as
those are not "Additional Standard Extensions". /shrug

> 
> And the Zb/Zk ones should come after the Zi ones, and before the
> supervisor level ones (The I category comes before the B or the K one).

This I agree with though.
Samuel Ortiz Nov. 24, 2022, 5:34 p.m. UTC | #7 
On Thu, Nov 24, 2022 at 05:20:37PM +0000, Conor Dooley wrote:
> On 24/11/2022 17:12, Samuel Ortiz wrote:
> > [You don't often get email from sameo@rivosinc.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > 
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > 
> > On Thu, Nov 24, 2022 at 11:55:01AM +0000, Conor Dooley wrote:
> >> On Thu, Nov 24, 2022 at 11:47:30AM +0100, Samuel Ortiz wrote:
> >>
> >>> Patch #1 is definitely needed regardless of which interface we pick for
> >>> exposing the ISA strings to userspace.
> >>
> >> I took another look at #1, and I feel more confused about what
> >> constitutes canonical order than I did before! If you know better than
> >> I, and you probably do since you're interested in these 6 month old
> >> patches, some insight would be appreciated!
> > 
> > Assuming we don't go with hwcap, I dont think the order of the
> > riscv_isa_ext_id enum matters that much?
> 
> The chief put it in canonical order so that's good enough for me!
> 
> > 
> > iiuc we're building the cpuinfo string from the riscv_isa_ext_data
> > array, and I think the current code is incorrect:
> > 
> > static struct riscv_isa_ext_data isa_ext_arr[] = {
> >     __RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF),
> >     __RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC),
> >     __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL),
> >     __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT),
> >     __RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM),
> >     __RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
> >     __RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX),
> > };
> > 
> > zicbom and zihintpause should come before supervisor level extensions.
> > I'm going to send a patch for that.
> 
> idk, Palmer explicitly re-ordered this:
> https://lore.kernel.org/linux-riscv/20220920204518.10988-1-palmer@rivosinc.com/
> 
> By my reading of the isa manual, what Palmer did is correct as
> those are not "Additional Standard Extensions". /shrug

Hmm, by their name (Z[a-b]+) they are Additional Standard Extensions.
What am I missing?

Cheers,
Samuel.
>
Conor Dooley Nov. 24, 2022, 5:54 p.m. UTC | #8 
On 24/11/2022 17:34, Samuel Ortiz wrote:
> On Thu, Nov 24, 2022 at 05:20:37PM +0000, Conor Dooley wrote:
>> On 24/11/2022 17:12, Samuel Ortiz wrote:
>>> [You don't often get email from sameo@rivosinc.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>>
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> On Thu, Nov 24, 2022 at 11:55:01AM +0000, Conor Dooley wrote:
>>>> On Thu, Nov 24, 2022 at 11:47:30AM +0100, Samuel Ortiz wrote:
>>>>
>>>>> Patch #1 is definitely needed regardless of which interface we pick for
>>>>> exposing the ISA strings to userspace.
>>>>
>>>> I took another look at #1, and I feel more confused about what
>>>> constitutes canonical order than I did before! If you know better than
>>>> I, and you probably do since you're interested in these 6 month old
>>>> patches, some insight would be appreciated!
>>>
>>> Assuming we don't go with hwcap, I dont think the order of the
>>> riscv_isa_ext_id enum matters that much?
>>
>> The chief put it in canonical order so that's good enough for me!
>>
>>>
>>> iiuc we're building the cpuinfo string from the riscv_isa_ext_data
>>> array, and I think the current code is incorrect:
>>>
>>> static struct riscv_isa_ext_data isa_ext_arr[] = {
>>>     __RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF),
>>>     __RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC),
>>>     __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL),
>>>     __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT),
>>>     __RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM),
>>>     __RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
>>>     __RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX),
>>> };
>>>
>>> zicbom and zihintpause should come before supervisor level extensions.
>>> I'm going to send a patch for that.
>>
>> idk, Palmer explicitly re-ordered this:
>> https://lore.kernel.org/linux-riscv/20220920204518.10988-1-palmer@rivosinc.com/
>>
>> By my reading of the isa manual, what Palmer did is correct as
>> those are not "Additional Standard Extensions". /shrug
> 
> Hmm, by their name (Z[a-b]+) they are Additional Standard Extensions.
> What am I missing?

Right, and this is where I get confused. Zam and Ztso *are* Additional
Standard Extensions, I think we can agree on that one? For those
extensions:
\chapter{``Ztso'' Standard Extension for Total Store Ordering, v0.1}
\chapter{``Zam'' Standard Extension for Misaligned Atomics, v0.1}

They're also called out specifically in the table:
https://github.com/riscv/riscv-isa-manual/blob/master/src/naming.tex#L147

For Zihintpause however:
\chapter{``Zihintpause'' Pause Hint, Version 2.0}

See what I mean? I looked at the specs for the bitmanip stuff and for
crypto, which both never mention being standard.

That table has the caption:
> The table also defines the canonical order in which extension names
> must appear in the name string, with top-to-bottom in table
> indicating first-to-last in the name string. 

It only calls out Zicsr, Zifencei, Zam and Ztso are being permitted
before Sdef, but as I said I am not a specs person, so perhaps some
of the extensions in question are intended to go there but have not
yet been merged into the isa manual doc. Zihintpause *is* in the
isa manual though but not specifically called out.

Anyways, hopefully that at least helps with my line of thinking!

Conor.
Samuel Ortiz Nov. 24, 2022, 6:09 p.m. UTC | #9 
On Thu, Nov 24, 2022 at 05:54:00PM +0000, Conor Dooley wrote:
> On 24/11/2022 17:34, Samuel Ortiz wrote:
> > On Thu, Nov 24, 2022 at 05:20:37PM +0000, Conor Dooley wrote:
> >> On 24/11/2022 17:12, Samuel Ortiz wrote:
> >>> [You don't often get email from sameo@rivosinc.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >>>
> >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>
> >>> On Thu, Nov 24, 2022 at 11:55:01AM +0000, Conor Dooley wrote:
> >>>> On Thu, Nov 24, 2022 at 11:47:30AM +0100, Samuel Ortiz wrote:
> >>>>
> >>>>> Patch #1 is definitely needed regardless of which interface we pick for
> >>>>> exposing the ISA strings to userspace.
> >>>>
> >>>> I took another look at #1, and I feel more confused about what
> >>>> constitutes canonical order than I did before! If you know better than
> >>>> I, and you probably do since you're interested in these 6 month old
> >>>> patches, some insight would be appreciated!
> >>>
> >>> Assuming we don't go with hwcap, I dont think the order of the
> >>> riscv_isa_ext_id enum matters that much?
> >>
> >> The chief put it in canonical order so that's good enough for me!
> >>
> >>>
> >>> iiuc we're building the cpuinfo string from the riscv_isa_ext_data
> >>> array, and I think the current code is incorrect:
> >>>
> >>> static struct riscv_isa_ext_data isa_ext_arr[] = {
> >>>     __RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF),
> >>>     __RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC),
> >>>     __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL),
> >>>     __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT),
> >>>     __RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM),
> >>>     __RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
> >>>     __RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX),
> >>> };
> >>>
> >>> zicbom and zihintpause should come before supervisor level extensions.
> >>> I'm going to send a patch for that.
> >>
> >> idk, Palmer explicitly re-ordered this:
> >> https://lore.kernel.org/linux-riscv/20220920204518.10988-1-palmer@rivosinc.com/
> >>
> >> By my reading of the isa manual, what Palmer did is correct as
> >> those are not "Additional Standard Extensions". /shrug
> > 
> > Hmm, by their name (Z[a-b]+) they are Additional Standard Extensions.
> > What am I missing?
> 
> Right, and this is where I get confused. Zam and Ztso *are* Additional
> Standard Extensions, I think we can agree on that one? For those
> extensions:
> \chapter{``Ztso'' Standard Extension for Total Store Ordering, v0.1}
> \chapter{``Zam'' Standard Extension for Misaligned Atomics, v0.1}
> 
> They're also called out specifically in the table:
> https://github.com/riscv/riscv-isa-manual/blob/master/src/naming.tex#L147
> 
> For Zihintpause however:
> \chapter{``Zihintpause'' Pause Hint, Version 2.0}
> 
> See what I mean? I looked at the specs for the bitmanip stuff and for
> crypto, which both never mention being standard.

I *think* this is because Zihintpause, bitmap and crypto are ratified
but not yet part of an official spec (non-draft) release?


> That table has the caption:
> > The table also defines the canonical order in which extension names
> > must appear in the name string, with top-to-bottom in table
> > indicating first-to-last in the name string. 
> 
> It only calls out Zicsr, Zifencei, Zam and Ztso are being permitted
> before Sdef, but as I said I am not a specs person, so perhaps some
> of the extensions in question are intended to go there but have not
> yet been merged into the isa manual doc. Zihintpause *is* in the
> isa manual though but not specifically called out.
> 
> Anyways, hopefully that at least helps with my line of thinking!
It does, thanks. It's a little confusing, I agree.

Cheers,
Samuel.
diff mbox series

Patch

diff --git a/arch/riscv/include/uapi/asm/hwcap.h b/arch/riscv/include/uapi/asm/hwcap.h
index 46dc3f5ee99f..bfed3e5c338c 100644
--- a/arch/riscv/include/uapi/asm/hwcap.h
+++ b/arch/riscv/include/uapi/asm/hwcap.h
@@ -22,4 +22,26 @@ 
 #define COMPAT_HWCAP_ISA_D	(1 << ('D' - 'A'))
 #define COMPAT_HWCAP_ISA_C	(1 << ('C' - 'A'))
 
+/*
+ * HWCAP2 flags - for elf_hwcap2 (in kernel) and AT_HWCAP2
+ *
+ * As only 32 bits of elf_hwcap (in kernel) could be used
+ * and RISC-V has reserved 26 bits of it, other caps like
+ * bitmanip and crypto can not be placed in AT_HWCAP
+ */
+#define COMPAT_HWCAP2_ISA_ZBA   (1 <<  0)
+#define COMPAT_HWCAP2_ISA_ZBB   (1 <<  1)
+#define COMPAT_HWCAP2_ISA_ZBC   (1 <<  2)
+#define COMPAT_HWCAP2_ISA_ZBS   (1 <<  3)
+#define COMPAT_HWCAP2_ISA_ZBKB  (1 <<  4)
+#define COMPAT_HWCAP2_ISA_ZBKC  (1 <<  5)
+#define COMPAT_HWCAP2_ISA_ZBKX  (1 <<  6)
+#define COMPAT_HWCAP2_ISA_ZKND  (1 <<  7)
+#define COMPAT_HWCAP2_ISA_ZKNE  (1 <<  8)
+#define COMPAT_HWCAP2_ISA_ZKNH  (1 <<  9)
+#define COMPAT_HWCAP2_ISA_ZKSED (1 << 10)
+#define COMPAT_HWCAP2_ISA_ZKSH  (1 << 11)
+#define COMPAT_HWCAP2_ISA_ZKR   (1 << 12)
+#define COMPAT_HWCAP2_ISA_ZKT   (1 << 13)
+
 #endif /* _UAPI_ASM_RISCV_HWCAP_H */