|
The following tries to capture and summarize what was discussed in today's meeting wrt what may be called the Embedded platform spec (versus the Linux platform spec). I know I have missed some things and gotten some things a bit wrong, so feel free to correct and add on to this. I also threw in a couple of narrower, detailed questions.
The point of this is to start email discussion and filling out of this high-level summary without waiting til the next meeting - especially from the people that are more knowledgeable about embedded systems and what can be standardized and what would be of value to standardize. Hopefully, since this spec is limited in what can be usefully standardized, this can be pushed forward in parallel with the bigger efforts towards fleshing out the framework for the Linux-2020/2022 platform spec(s) - especially by people interested in this spec. (Put differently, we can't afford to only make progress at the rate of one hour a week. And we need to parallelize the two platform efforts. Then the biweekly meetings can be sync-up points and discussion of key issues. And hopefully the basics of a draft Embedded platform spec won't take all that long either.)
- Don't call it a "bare metal" or "non-Linux" spec, just "embedded" (to span a range of hardware/software environments)
- Practically speaking any Embedded platform spec is primarily of forward-looking value - for new designs to conform to
- Focus on Embedded-2022 spec
- No Embedded-2020 spec (since there is limited compatibility across today's systems)
- Can only standardize a limited set of basics (given the wide variety and needs of embedded systems):
- Require RVM22 (with no turning of any optional items into required items)
- Feedback to RVM22 definition group about any needed finer-granularity arch extension breakdowns?
- E.g. mul without div?
- E.g. just parts of S-mode if S-mode supported?
- Wrt the many WARL options in M-mode and S-mode Priv specs, any required values?
-
Require "CLIC and/or PLIC"
- CLIC from Fast Interrupts TG; need to create a "standard" PLIC spec
-
Require
CLINT (or rough equivalent)
- Or require "CLINT or CLIC" if CLIC includes CLINT functionality (for timer and s/w interrupts)?
- Need to create a "standard" CLINT spec
- EABI and/or other ABIs as options? Maybe not of value.
- Minimum PMP config (if optionally implemented)
- This is an example of the above item about WARL options in the Priv spec
- ???
Greg
|
|
|
Allen Baum
for what it's worth: I would love it if there was a requirement that a write of an illegal value to a WARL field left the field unchanged. The illegal to legal mapping function can be any that is deterministically defined by the values being written and the state of the hart (which include the value of the specific CSR field) That's a rather wide-open range of options. Leaving it unchanged is - one of the legal possibilities, - likely one of the easiest to implement, and - one of the few mappings that the architectural tests (and riscv-config) know about.
On Mon, Feb 1, 2021 at 9:59 PM Greg Favor < gfavor@...> wrote: The following tries to capture and summarize what was discussed in today's meeting wrt what may be called the Embedded platform spec (versus the Linux platform spec). I know I have missed some things and gotten some things a bit wrong, so feel free to correct and add on to this. I also threw in a couple of narrower, detailed questions.
The point of this is to start email discussion and filling out of this high-level summary without waiting til the next meeting - especially from the people that are more knowledgeable about embedded systems and what can be standardized and what would be of value to standardize. Hopefully, since this spec is limited in what can be usefully standardized, this can be pushed forward in parallel with the bigger efforts towards fleshing out the framework for the Linux-2020/2022 platform spec(s) - especially by people interested in this spec. (Put differently, we can't afford to only make progress at the rate of one hour a week. And we need to parallelize the two platform efforts. Then the biweekly meetings can be sync-up points and discussion of key issues. And hopefully the basics of a draft Embedded platform spec won't take all that long either.)
- Don't call it a "bare metal" or "non-Linux" spec, just "embedded" (to span a range of hardware/software environments)
- Practically speaking any Embedded platform spec is primarily of forward-looking value - for new designs to conform to
- Focus on Embedded-2022 spec
- No Embedded-2020 spec (since there is limited compatibility across today's systems)
- Can only standardize a limited set of basics (given the wide variety and needs of embedded systems):
- Require RVM22 (with no turning of any optional items into required items)
- Feedback to RVM22 definition group about any needed finer-granularity arch extension breakdowns?
- E.g. mul without div?
- E.g. just parts of S-mode if S-mode supported?
- Wrt the many WARL options in M-mode and S-mode Priv specs, any required values?
-
Require "CLIC and/or PLIC"
- CLIC from Fast Interrupts TG; need to create a "standard" PLIC spec
-
Require
CLINT (or rough equivalent)
- Or require "CLINT or CLIC" if CLIC includes CLINT functionality (for timer and s/w interrupts)?
- Need to create a "standard" CLINT spec
- EABI and/or other ABIs as options? Maybe not of value.
- Minimum PMP config (if optionally implemented)
- This is an example of the above item about WARL options in the Priv spec
- ???
Greg
|
|
|
Richard Newell
Hi Greg, et al;
We expect Krypto Scalar specification to be ratified this year. It is a lightweight extension designed especially for embedded systems. The Krypto TG recommends the “K” extension be at least an optional part of the RVx22 profiles.
“K” (as proposed) includes the NIST suite for AES encryption/decryption, SHA2 hashes, assorted necessary bit-manipulation instructions, carry-less multiply (needed for GCM) and the random entropy source, i.e., enough to do TLS or HTTPS,
secure boot, and other basic cryptography using the most popular US standards. “K” could be optionally extended with Zks (as proposed) which includes lightweight support for the Chinese national cipher and hash algorithms.
The Krypto Scalar specification is currently “stable” and undergoing opcode (and etc.) review in preparation for “freeze” and public review.
Rich
G. Richard Newell
Assoc. Technical Fellow, FPGA Business Unit, Microchip Technology
(408) 643-6146 (office), (408) 882-4785 (mobile),
+1 (925) 478-7258 (Skype)
|
PGP: (2009 DSA-1024, ELG-4096) B751 FC13 8B4E 49DA 2270 35A2 20E4 E66A D0D0 2E34
(2016 SSA-4096, RSA-4096) 65F5 CCD6 23B3 BD3D CEDE AB58 171F F4DE E7D0 3ECA
|
toggle quoted message
Show quoted text
From: tech-unixplatformspec@... <tech-unixplatformspec@...>
On Behalf Of Greg Favor
Sent: Monday, February 01, 2021 10:00 PM
To: tech-unixplatformspec@...
Cc: Greg Favor <gfavor@...>
Subject: [RISC-V] [tech-unixplatformspec] Partial summary of potential Embedded-2022 platform spec discussion
EXTERNAL EMAIL:
Do not click links or open attachments unless you know the content is safe
The following tries to capture and summarize what was discussed in today's meeting wrt what may be called the Embedded platform spec (versus the Linux platform spec). I know I have missed some things and gotten some things a bit wrong,
so feel free to correct and add on to this. I also threw in a couple of narrower, detailed questions.
The point of this is to start email discussion and filling out of this high-level summary without waiting til the next meeting - especially from the people that are more knowledgeable about embedded systems and what can be standardized
and what would be of value to standardize. Hopefully, since this spec is limited in what can be usefully standardized, this can be pushed forward in parallel with the bigger efforts towards fleshing out the framework for the Linux-2020/2022 platform spec(s)
- especially by people interested in this spec. (Put differently, we can't afford to only make progress at the rate of one hour a week. And we need to parallelize the two platform efforts. Then the biweekly meetings can be sync-up points and discussion
of key issues. And hopefully the basics of a draft Embedded platform spec won't take all that long either.)
-
Don't call it a "bare metal" or "non-Linux" spec, just "embedded" (to span a range of hardware/software environments)
-
Practically speaking any Embedded platform spec is primarily of forward-looking value - for new designs to conform to
-
Focus on Embedded-2022 spec
-
No Embedded-2020 spec (since there is limited compatibility across today's systems)
-
Can only standardize a limited set of basics (given the wide variety and needs of embedded systems):
-
Require RVM22 (with no turning of any optional items into required items)
-
Feedback to RVM22 definition group about any needed finer-granularity arch extension breakdowns?
-
E.g. mul without div?
-
E.g. just parts of S-mode if S-mode supported?
-
Wrt the many WARL options in M-mode and S-mode Priv specs, any required values?
-
Require "CLIC and/or PLIC"
-
CLIC from Fast Interrupts TG; need to create a "standard" PLIC spec
-
Require CLINT (or rough equivalent)
-
Or require "CLINT or CLIC" if CLIC includes CLINT functionality (for timer and s/w interrupts)?
-
Need to create a "standard" CLINT spec
-
EABI and/or other ABIs as options? Maybe not of value.
-
Minimum PMP config (if optionally implemented)
-
This is an example of the above item about WARL options in the Priv spec
|
|
|
for what it's worth: I would love it if there was a requirement that a write of an illegal value to a WARL field left the field unchanged.
I imagine this would be best addressed as part of the profile specs (versus platform specs). Maybe have a talk with Krste and Andrew who are in the thick of that work?
Greg The illegal to legal mapping function can be any that is deterministically defined by the values being written and the state of the hart (which include the value of the specific CSR field) That's a rather wide-open range of options. Leaving it unchanged is - one of the legal possibilities, - likely one of the easiest to implement, and - one of the few mappings that the architectural tests (and riscv-config) know about.
On Mon, Feb 1, 2021 at 9:59 PM Greg Favor < gfavor@...> wrote: The following tries to capture and summarize what was discussed in today's meeting wrt what may be called the Embedded platform spec (versus the Linux platform spec). I know I have missed some things and gotten some things a bit wrong, so feel free to correct and add on to this. I also threw in a couple of narrower, detailed questions.
The point of this is to start email discussion and filling out of this high-level summary without waiting til the next meeting - especially from the people that are more knowledgeable about embedded systems and what can be standardized and what would be of value to standardize. Hopefully, since this spec is limited in what can be usefully standardized, this can be pushed forward in parallel with the bigger efforts towards fleshing out the framework for the Linux-2020/2022 platform spec(s) - especially by people interested in this spec. (Put differently, we can't afford to only make progress at the rate of one hour a week. And we need to parallelize the two platform efforts. Then the biweekly meetings can be sync-up points and discussion of key issues. And hopefully the basics of a draft Embedded platform spec won't take all that long either.)
- Don't call it a "bare metal" or "non-Linux" spec, just "embedded" (to span a range of hardware/software environments)
- Practically speaking any Embedded platform spec is primarily of forward-looking value - for new designs to conform to
- Focus on Embedded-2022 spec
- No Embedded-2020 spec (since there is limited compatibility across today's systems)
- Can only standardize a limited set of basics (given the wide variety and needs of embedded systems):
- Require RVM22 (with no turning of any optional items into required items)
- Feedback to RVM22 definition group about any needed finer-granularity arch extension breakdowns?
- E.g. mul without div?
- E.g. just parts of S-mode if S-mode supported?
- Wrt the many WARL options in M-mode and S-mode Priv specs, any required values?
-
Require "CLIC and/or PLIC"
- CLIC from Fast Interrupts TG; need to create a "standard" PLIC spec
-
Require
CLINT (or rough equivalent)
- Or require "CLINT or CLIC" if CLIC includes CLINT functionality (for timer and s/w interrupts)?
- Need to create a "standard" CLINT spec
- EABI and/or other ABIs as options? Maybe not of value.
- Minimum PMP config (if optionally implemented)
- This is an example of the above item about WARL options in the Priv spec
- ???
Greg
|
|
|
Hi Greg, et al;
We expect Krypto Scalar specification to be ratified this year. It is a lightweight extension designed especially for embedded systems. The Krypto TG recommends the “K” extension be at least an optional part of the RVx22 profiles.
This definitely falls under the purview of the profile specs, not the platform specs. I suggest contacting Krste and Mark about this. The effort to put together the profile specs is just getting started (but expected to complete in a couple of months).
Off-hand I would imagine that this extension _will_ be part of one or both profiles (and probably as optional).
Greg
“K” (as proposed) includes the NIST suite for AES encryption/decryption, SHA2 hashes, assorted necessary bit-manipulation instructions, carry-less multiply (needed for GCM) and the random entropy source, i.e., enough to do TLS or HTTPS,
secure boot, and other basic cryptography using the most popular US standards. “K” could be optionally extended with Zks (as proposed) which includes lightweight support for the Chinese national cipher and hash algorithms.
The Krypto Scalar specification is currently “stable” and undergoing opcode (and etc.) review in preparation for “freeze” and public review.
Rich
G. Richard Newell
Assoc. Technical Fellow, FPGA Business Unit, Microchip Technology
(408) 643-6146 (office), (408) 882-4785 (mobile),
+1 (925) 478-7258 (Skype)
|
PGP: (2009 DSA-1024, ELG-4096) B751 FC13 8B4E 49DA 2270 35A2 20E4 E66A D0D0 2E34
(2016 SSA-4096, RSA-4096) 65F5 CCD6 23B3 BD3D CEDE AB58 171F F4DE E7D0 3ECA
|
EXTERNAL EMAIL:
Do not click links or open attachments unless you know the content is safe
The following tries to capture and summarize what was discussed in today's meeting wrt what may be called the Embedded platform spec (versus the Linux platform spec). I know I have missed some things and gotten some things a bit wrong,
so feel free to correct and add on to this. I also threw in a couple of narrower, detailed questions.
The point of this is to start email discussion and filling out of this high-level summary without waiting til the next meeting - especially from the people that are more knowledgeable about embedded systems and what can be standardized
and what would be of value to standardize. Hopefully, since this spec is limited in what can be usefully standardized, this can be pushed forward in parallel with the bigger efforts towards fleshing out the framework for the Linux-2020/2022 platform spec(s)
- especially by people interested in this spec. (Put differently, we can't afford to only make progress at the rate of one hour a week. And we need to parallelize the two platform efforts. Then the biweekly meetings can be sync-up points and discussion
of key issues. And hopefully the basics of a draft Embedded platform spec won't take all that long either.)
-
Don't call it a "bare metal" or "non-Linux" spec, just "embedded" (to span a range of hardware/software environments)
-
Practically speaking any Embedded platform spec is primarily of forward-looking value - for new designs to conform to
-
Focus on Embedded-2022 spec
-
No Embedded-2020 spec (since there is limited compatibility across today's systems)
-
Can only standardize a limited set of basics (given the wide variety and needs of embedded systems):
-
Require RVM22 (with no turning of any optional items into required items)
-
Feedback to RVM22 definition group about any needed finer-granularity arch extension breakdowns?
-
E.g. mul without div?
-
E.g. just parts of S-mode if S-mode supported?
-
Wrt the many WARL options in M-mode and S-mode Priv specs, any required values?
-
Require "CLIC and/or PLIC"
-
CLIC from Fast Interrupts TG; need to create a "standard" PLIC spec
-
Require CLINT (or rough equivalent)
-
Or require "CLINT or CLIC" if CLIC includes CLINT functionality (for timer and s/w interrupts)?
-
Need to create a "standard" CLINT spec
-
EABI and/or other ABIs as options? Maybe not of value.
-
Minimum PMP config (if optionally implemented)
-
This is an example of the above item about WARL options in the Priv spec
|
|
|
Greg & Richard, On Tue, Feb 2, 2021 at 5:47 PM Greg Favor < gfavor@...> wrote:
Hi Greg, et al;
We expect Krypto Scalar specification to be ratified this year. It is a lightweight extension designed especially for embedded systems. The Krypto TG recommends the “K” extension be at least an optional part of the RVx22 profiles.
This definitely falls under the purview of the profile specs, not the platform specs. I suggest contacting Krste and Mark about this. The effort to put together the profile specs is just getting started (but expected to complete in a couple of months).
Off-hand I would imagine that this extension _will_ be part of one or both profiles (and probably as optional).
I would hope that the profiles provide this at least as optional.
On the platforms side, we will then build (at least for the Linux-2022 profile) on this by mandating runtime discovery and support for it. The details on how this support can/will look are still sketchy, however the following assertions should remain unchanged: - OS kernels claiming compliance with Linux-2022 will have a discovery mechanism (details are TBD; might be as simple as a bootloader passing in a flag via the DTB) to detect if K-support is present in hardware.
- OS kernels claiming compliance with Linux-2022 will expose the availability of K-instructions to userspace applications (e.g. auxval or hwcaps).
- OS kernels claiming compliance with Linux-2022 will be able to determine (from an ELF binary) if it contains K-instructions or not — and will only execute code requiring K-instructions if support is present.
In addition, we'd like to see some adoption of crypto instructions for the benefit of users: - OS kernels will be encouraged to make use of K-instructions for crypto operations in the kernel (e.g. networking-related).
- OS distributions will be encouraged to provide optimized support (ifunc, additional DSOs) using K-instructions for crypto operations in userspace (e.g. in OpenSSL).
If the "will be encouraged" will be a non-binding recommendation or if we will add this to an additional "package" (that implementations can claim conformance to), is to be seen and should become clearer by April.
Philipp.
|
|
|
Alistair Francis <alistair.francis@...>
On Tue, 2021-02-02 at 18:08 +0100, Philipp Tomsich wrote: Greg & Richard,
On Tue, Feb 2, 2021 at 5:47 PM Greg Favor <gfavor@...>
wrote:
On Tue, Feb 2, 2021 at 12:31 AM <Richard.Newell@...>
wrote:
Hi Greg, et al;
We expect Krypto Scalar specification to be ratified this year.
It is a lightweight extension designed especially for embedded
systems. The Krypto TG recommends the “K” extension be at least
an optional part of the RVx22 profiles.
This definitely falls under the purview of the profile specs, not
the platform specs. I suggest contacting Krste and Mark about
this. The effort to put together the profile specs is just getting
started (but expected to complete in a couple of months).
Off-hand I would imagine that this extension _will_ be part of one
or both profiles (and probably as optional).
I would hope that the profiles provide this at least as optional. I'm not clear what we mean here. For the embedded spec all extensiosn will be optional, that would include ratified, frozen draft and vendour extensions. Alistair
On the platforms side, we will then build (at least for the Linux-
2022 profile) on this by mandating runtime discovery and support for
it.
The details on how this support can/will look are still sketchy,
however the following assertions should remain unchanged:
* OS kernels claiming compliance with Linux-2022 will have a
discovery mechanism (details are TBD; might be as simple as a
bootloader passing in a flag via the DTB) to detect if K-support is
present in hardware.
* OS kernels claiming compliance with Linux-2022 will expose the
availability of K-instructions to userspace applications (e.g. auxval
or hwcaps).
* * OS kernels claiming compliance with Linux-2022 will be able to
determine (from an ELF binary) if it contains K-instructions or not —
and will only execute code requiring K-instructions if support is
present.
In addition, we'd like to see some adoption of crypto instructions
for the benefit of users:
* * OS kernels will be encouraged to make use of K-instructions for
crypto operations in the kernel (e.g. networking-related).
* OS distributions will be encouraged to provide optimized support
(ifunc, additional DSOs) using K-instructions for crypto operations
in userspace (e.g. in OpenSSL).
If the "will be encouraged" will be a non-binding recommendation or
if we will add this to an additional "package" (that implementations
can claim conformance to), is to be seen and should become clearer by
April.
Philipp.
|
|
|
Jonathan Behrens <behrensj@...>
Is there an assumption that the only OS kernels claiming compliance with Linux-2022 will actually be versions of the Linux kernel? Given the name, it seems like it would be kind of awkward for a competitor to claim that
Jonathan
On Tue, 2021-02-02 at 18:08 +0100, Philipp Tomsich wrote:
> Greg & Richard,
>
> On Tue, Feb 2, 2021 at 5:47 PM Greg Favor <gfavor@...>
> wrote:
> > On Tue, Feb 2, 2021 at 12:31 AM <Richard.Newell@...>
> > wrote:
> > > Hi Greg, et al;
> > >
> > > We expect Krypto Scalar specification to be ratified this year.
> > > It is a lightweight extension designed especially for embedded
> > > systems. The Krypto TG recommends the “K” extension be at least
> > > an optional part of the RVx22 profiles.
> > >
> >
> > This definitely falls under the purview of the profile specs, not
> > the platform specs. I suggest contacting Krste and Mark about
> > this. The effort to put together the profile specs is just getting
> > started (but expected to complete in a couple of months).
> >
> > Off-hand I would imagine that this extension _will_ be part of one
> > or both profiles (and probably as optional).
> >
>
> I would hope that the profiles provide this at least as optional.
I'm not clear what we mean here. For the embedded spec all extensiosn
will be optional, that would include ratified, frozen draft and vendour
extensions.
Alistair
>
> On the platforms side, we will then build (at least for the Linux-
> 2022 profile) on this by mandating runtime discovery and support for
> it.
> The details on how this support can/will look are still sketchy,
> however the following assertions should remain unchanged:
> * OS kernels claiming compliance with Linux-2022 will have a
> discovery mechanism (details are TBD; might be as simple as a
> bootloader passing in a flag via the DTB) to detect if K-support is
> present in hardware.
> * OS kernels claiming compliance with Linux-2022 will expose the
> availability of K-instructions to userspace applications (e.g. auxval
> or hwcaps).
> * * OS kernels claiming compliance with Linux-2022 will be able to
> determine (from an ELF binary) if it contains K-instructions or not —
> and will only execute code requiring K-instructions if support is
> present.
> In addition, we'd like to see some adoption of crypto instructions
> for the benefit of users:
> * * OS kernels will be encouraged to make use of K-instructions for
> crypto operations in the kernel (e.g. networking-related).
> * OS distributions will be encouraged to provide optimized support
> (ifunc, additional DSOs) using K-instructions for crypto operations
> in userspace (e.g. in OpenSSL).
> If the "will be encouraged" will be a non-binding recommendation or
> if we will add this to an additional "package" (that implementations
> can claim conformance to), is to be seen and should become clearer by
> April.
>
> Philipp.
>
|
|
|
The current name is just a convenient internal placeholder, but the intent is to be applicable to "Rich OS's" (such as all your Unix variants, Windows variants, even something like QNX).
Greg
On Tue, Feb 2, 2021 at 10:15 AM Jonathan Behrens < behrensj@...> wrote: Is there an assumption that the only OS kernels claiming compliance with Linux-2022 will actually be versions of the Linux kernel? Given the name, it seems like it would be kind of awkward for a competitor to claim that
Jonathan
On Tue, 2021-02-02 at 18:08 +0100, Philipp Tomsich wrote:
> Greg & Richard,
>
> On Tue, Feb 2, 2021 at 5:47 PM Greg Favor <gfavor@...>
> wrote:
> > On Tue, Feb 2, 2021 at 12:31 AM <Richard.Newell@...>
> > wrote:
> > > Hi Greg, et al;
> > >
> > > We expect Krypto Scalar specification to be ratified this year.
> > > It is a lightweight extension designed especially for embedded
> > > systems. The Krypto TG recommends the “K” extension be at least
> > > an optional part of the RVx22 profiles.
> > >
> >
> > This definitely falls under the purview of the profile specs, not
> > the platform specs. I suggest contacting Krste and Mark about
> > this. The effort to put together the profile specs is just getting
> > started (but expected to complete in a couple of months).
> >
> > Off-hand I would imagine that this extension _will_ be part of one
> > or both profiles (and probably as optional).
> >
>
> I would hope that the profiles provide this at least as optional.
I'm not clear what we mean here. For the embedded spec all extensiosn
will be optional, that would include ratified, frozen draft and vendour
extensions.
Alistair
>
> On the platforms side, we will then build (at least for the Linux-
> 2022 profile) on this by mandating runtime discovery and support for
> it.
> The details on how this support can/will look are still sketchy,
> however the following assertions should remain unchanged:
> * OS kernels claiming compliance with Linux-2022 will have a
> discovery mechanism (details are TBD; might be as simple as a
> bootloader passing in a flag via the DTB) to detect if K-support is
> present in hardware.
> * OS kernels claiming compliance with Linux-2022 will expose the
> availability of K-instructions to userspace applications (e.g. auxval
> or hwcaps).
> * * OS kernels claiming compliance with Linux-2022 will be able to
> determine (from an ELF binary) if it contains K-instructions or not —
> and will only execute code requiring K-instructions if support is
> present.
> In addition, we'd like to see some adoption of crypto instructions
> for the benefit of users:
> * * OS kernels will be encouraged to make use of K-instructions for
> crypto operations in the kernel (e.g. networking-related).
> * OS distributions will be encouraged to provide optimized support
> (ifunc, additional DSOs) using K-instructions for crypto operations
> in userspace (e.g. in OpenSSL).
> If the "will be encouraged" will be a non-binding recommendation or
> if we will add this to an additional "package" (that implementations
> can claim conformance to), is to be seen and should become clearer by
> April.
>
> Philipp.
>
|
|
|
Linux-2022 is just working title... and we expect the final name to be more neutral. Calling it “rich OS” didn’t really work to convey the direction to the audience.
The Linux name was chosen to have concepts such from distros to building from source in scope... we’ve always tried to be vocal that this platform needs to address at least the *BSD variants and (possibly) rich RTOSes.
In the end, a name will just be a name. At this early stage, the working title needs to help focus us on real-world use cases and challenges...
Cheers, Philipp.
On Tue 2. Feb 2021 at 19:15, Jonathan Behrens < behrensj@...> wrote: Is there an assumption that the only OS kernels claiming compliance with Linux-2022 will actually be versions of the Linux kernel? Given the name, it seems like it would be kind of awkward for a competitor to claim that
Jonathan
On Tue, 2021-02-02 at 18:08 +0100, Philipp Tomsich wrote:
> Greg & Richard,
>
> On Tue, Feb 2, 2021 at 5:47 PM Greg Favor <gfavor@...>
> wrote:
> > On Tue, Feb 2, 2021 at 12:31 AM <Richard.Newell@...>
> > wrote:
> > > Hi Greg, et al;
> > >
> > > We expect Krypto Scalar specification to be ratified this year.
> > > It is a lightweight extension designed especially for embedded
> > > systems. The Krypto TG recommends the “K” extension be at least
> > > an optional part of the RVx22 profiles.
> > >
> >
> > This definitely falls under the purview of the profile specs, not
> > the platform specs. I suggest contacting Krste and Mark about
> > this. The effort to put together the profile specs is just getting
> > started (but expected to complete in a couple of months).
> >
> > Off-hand I would imagine that this extension _will_ be part of one
> > or both profiles (and probably as optional).
> >
>
> I would hope that the profiles provide this at least as optional.
I'm not clear what we mean here. For the embedded spec all extensiosn
will be optional, that would include ratified, frozen draft and vendour
extensions.
Alistair
>
> On the platforms side, we will then build (at least for the Linux-
> 2022 profile) on this by mandating runtime discovery and support for
> it.
> The details on how this support can/will look are still sketchy,
> however the following assertions should remain unchanged:
> * OS kernels claiming compliance with Linux-2022 will have a
> discovery mechanism (details are TBD; might be as simple as a
> bootloader passing in a flag via the DTB) to detect if K-support is
> present in hardware.
> * OS kernels claiming compliance with Linux-2022 will expose the
> availability of K-instructions to userspace applications (e.g. auxval
> or hwcaps).
> * * OS kernels claiming compliance with Linux-2022 will be able to
> determine (from an ELF binary) if it contains K-instructions or not —
> and will only execute code requiring K-instructions if support is
> present.
> In addition, we'd like to see some adoption of crypto instructions
> for the benefit of users:
> * * OS kernels will be encouraged to make use of K-instructions for
> crypto operations in the kernel (e.g. networking-related).
> * OS distributions will be encouraged to provide optimized support
> (ifunc, additional DSOs) using K-instructions for crypto operations
> in userspace (e.g. in OpenSSL).
> If the "will be encouraged" will be a non-binding recommendation or
> if we will add this to an additional "package" (that implementations
> can claim conformance to), is to be seen and should become clearer by
> April.
>
> Philipp.
>
|
|
|
On Tue, 2021-02-02 at 19:33 +0100, Philipp Tomsich wrote: Linux-2022 is just working title... and we expect the final name to
be more neutral.
Calling it “rich OS” didn’t really work to convey the direction to
the audience.
I agree. I am also not sure calling embedded-2022 is a good idea either. That may confuse outside folks to think that it is meant for embedded Linux. Al had a better suggestion about the naming. The specification can be called as Operating System platform specification (OSPS). How about this ? OSPS2022-L0 - targets micro-controllers booting RTOS (zephyr, FreeRTOS etc) OSPS2022-L1 - targets hardware capable of booting rich OS such as Unix/Windows We will never have more than two levels but each specification will evolve at 2 years cadence & different version numbers. For example: The next version of the specifications will be called OSPS2024-L0 & OSPS2021-L1 Any incremental updates will be just have a minor number versioning. The Linux name was chosen to have concepts such from distros to
building from source in scope... we’ve always tried to be vocal that
this platform needs to address at least the *BSD variants and
(possibly) rich RTOSes.
In the end, a name will just be a name.
At this early stage, the working title needs to help focus us on
real-world use cases and challenges...
Cheers,
Philipp.
On Tue 2. Feb 2021 at 19:15, Jonathan Behrens <behrensj@...>
wrote:
Is there an assumption that the only OS kernels claiming
compliance with Linux-2022 will actually be versions of the Linux
kernel? Given the name, it seems like it would be kind of awkward
for a competitor to claim that
Jonathan
On Tue, Feb 2, 2021 at 12:57 PM Alistair Francis via
lists.riscv.org <alistair.francis=wdc.com@...> wrote:
On Tue, 2021-02-02 at 18:08 +0100, Philipp Tomsich wrote:
Greg & Richard,
On Tue, Feb 2, 2021 at 5:47 PM Greg Favor <gfavor@...>
wrote:
On Tue, Feb 2, 2021 at 12:31 AM <Richard.Newell@...>
wrote:
Hi Greg, et al;
We expect Krypto Scalar specification to be ratified this
year.
It is a lightweight extension designed especially for
embedded
systems. The Krypto TG recommends the “K” extension be at
least
an optional part of the RVx22 profiles.
This definitely falls under the purview of the profile specs,
not
the platform specs. I suggest contacting Krste and Mark
about
this. The effort to put together the profile specs is just
getting
started (but expected to complete in a couple of months).
Off-hand I would imagine that this extension _will_ be part
of one
or both profiles (and probably as optional).
I would hope that the profiles provide this at least as
optional.
I'm not clear what we mean here. For the embedded spec all
extensiosn
will be optional, that would include ratified, frozen draft and
vendour
extensions.
Alistair
On the platforms side, we will then build (at least for the
Linux-
2022 profile) on this by mandating runtime discovery and support for
it.
The details on how this support can/will look are still sketchy,
however the following assertions should remain unchanged:
* OS kernels claiming compliance with Linux-2022 will have a
discovery mechanism (details are TBD; might be as simple as a
bootloader passing in a flag via the DTB) to detect if K- support is
present in hardware.
* OS kernels claiming compliance with Linux-2022 will expose the
availability of K-instructions to userspace applications (e.g. auxval
or hwcaps).
* * OS kernels claiming compliance with Linux-2022 will be able to
determine (from an ELF binary) if it contains K-instructions or not —
and will only execute code requiring K-instructions if support is
present.
In addition, we'd like to see some adoption of crypto instructions
for the benefit of users:
* * OS kernels will be encouraged to make use of K- instructions for
crypto operations in the kernel (e.g. networking-related).
* OS distributions will be encouraged to provide optimized support
(ifunc, additional DSOs) using K-instructions for crypto operations
in userspace (e.g. in OpenSSL).
If the "will be encouraged" will be a non-binding recommendation or
if we will add this to an additional "package" (that implementations
can claim conformance to), is to be seen and should become clearer by
April.
Philipp.
-- Regards, Atish
|
|
|
I would prefer to have “visual” names while we work on this and move towards a neutral name as we near the review cycles (to remove some of the bias that we want initially).
On Tue, 2021-02-02 at 19:33 +0100, Philipp Tomsich wrote:
> Linux-2022 is just working title... and we expect the final name to
> be more neutral.
> Calling it “rich OS” didn’t really work to convey the direction to
> the audience.
>
I agree. I am also not sure calling embedded-2022 is a good idea
either. That may confuse outside folks to think that it is meant for
embedded Linux. Al had a better suggestion about the naming.
The specification can be called as Operating System platform
specification (OSPS).
How about this ?
OSPS2022-L0 - targets micro-controllers booting RTOS (zephyr, FreeRTOS
etc)
OSPS2022-L1 - targets hardware capable of booting rich OS such as
Unix/Windows
We will never have more than two levels but each specification will
evolve at 2 years cadence & different version numbers. For example:
The next version of the specifications will be called
OSPS2024-L0 & OSPS2021-L1
Any incremental updates will be just have a minor number versioning.
> The Linux name was chosen to have concepts such from distros to
> building from source in scope... we’ve always tried to be vocal that
> this platform needs to address at least the *BSD variants and
> (possibly) rich RTOSes.
>
> In the end, a name will just be a name.
> At this early stage, the working title needs to help focus us on
> real-world use cases and challenges...
>
> Cheers,
> Philipp.
>
> On Tue 2. Feb 2021 at 19:15, Jonathan Behrens <behrensj@...>
> wrote:
> > Is there an assumption that the only OS kernels claiming
> > compliance with Linux-2022 will actually be versions of the Linux
> > kernel? Given the name, it seems like it would be kind of awkward
> > for a competitor to claim that
> >
> > Jonathan
> >
> > On Tue, Feb 2, 2021 at 12:57 PM Alistair Francis via
> > lists.riscv.org <alistair.francis=wdc.com@...> wrote:
> >
> > > On Tue, 2021-02-02 at 18:08 +0100, Philipp Tomsich wrote:
> > > > Greg & Richard,
> > > >
> > > > On Tue, Feb 2, 2021 at 5:47 PM Greg Favor
> > > <gfavor@...>
> > > > wrote:
> > > > > On Tue, Feb 2, 2021 at 12:31 AM
> > > <Richard.Newell@...>
> > > > > wrote:
> > > > > > Hi Greg, et al;
> > > > > >
> > > > > > We expect Krypto Scalar specification to be ratified this
> > > year.
> > > > > > It is a lightweight extension designed especially for
> > > embedded
> > > > > > systems. The Krypto TG recommends the “K” extension be at
> > > least
> > > > > > an optional part of the RVx22 profiles.
> > > > > >
> > > > >
> > > > > This definitely falls under the purview of the profile specs,
> > > not
> > > > > the platform specs. I suggest contacting Krste and Mark
> > > about
> > > > > this. The effort to put together the profile specs is just
> > > getting
> > > > > started (but expected to complete in a couple of months).
> > > > >
> > > > > Off-hand I would imagine that this extension _will_ be part
> > > of one
> > > > > or both profiles (and probably as optional).
> > > > >
> > > >
> > > > I would hope that the profiles provide this at least as
> > > optional.
> > >
> > > I'm not clear what we mean here. For the embedded spec all
> > > extensiosn
> > > will be optional, that would include ratified, frozen draft and
> > > vendour
> > > extensions.
> > >
> > > Alistair
> > >
> > > >
> > > > On the platforms side, we will then build (at least for the
> > > Linux-
> > > > 2022 profile) on this by mandating runtime discovery and
> > > support for
> > > > it.
> > > > The details on how this support can/will look are still
> > > sketchy,
> > > > however the following assertions should remain unchanged:
> > > > * OS kernels claiming compliance with Linux-2022 will have a
> > > > discovery mechanism (details are TBD; might be as simple as a
> > > > bootloader passing in a flag via the DTB) to detect if K-
> > > support is
> > > > present in hardware.
> > > > * OS kernels claiming compliance with Linux-2022 will expose
> > > the
> > > > availability of K-instructions to userspace applications (e.g.
> > > auxval
> > > > or hwcaps).
> > > > * * OS kernels claiming compliance with Linux-2022 will be
> > > able to
> > > > determine (from an ELF binary) if it contains K-instructions or
> > > not —
> > > > and will only execute code requiring K-instructions if support
> > > is
> > > > present.
> > > > In addition, we'd like to see some adoption of crypto
> > > instructions
> > > > for the benefit of users:
> > > > * * OS kernels will be encouraged to make use of K-
> > > instructions for
> > > > crypto operations in the kernel (e.g. networking-related).
> > > > * OS distributions will be encouraged to provide optimized
> > > support
> > > > (ifunc, additional DSOs) using K-instructions for crypto
> > > operations
> > > > in userspace (e.g. in OpenSSL).
> > > > If the "will be encouraged" will be a non-binding
> > > recommendation or
> > > > if we will add this to an additional "package" (that
> > > implementations
> > > > can claim conformance to), is to be seen and should become
> > > clearer by
> > > > April.
> > > >
> > > > Philipp.
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
>
--
Regards,
Atish
|
|
|
On Mon, 2021-02-01 at 21:59 -0800, Greg Favor wrote: The following tries to capture and summarize what was discussed in
today's meeting wrt what may be called the Embedded platform spec
(versus the Linux platform spec). I know I have missed some things
and gotten some things a bit wrong, so feel free to correct and add
on to this. I also threw in a couple of narrower,
detailed questions. Thanks Greg. The point of this is to start email discussion and filling out of
this high-level summary without waiting til the next meeting -
especially from the people that are more knowledgeable about embedded
systems and what can be standardized and what would be of value to
standardize. Hopefully, since this spec is limited in what can be
usefully standardized, this can be pushed forward in parallel with
the bigger efforts towards fleshing out the framework for the Linux-
2020/2022 platform spec(s) - especially by people interested in this
spec. (Put differently, we can't afford to only make progress at the
rate of one hour a week. And we need to parallelize the two platform
efforts. Then the biweekly meetings can be sync-up points and
discussion of key issues. And hopefully the basics of a draft
Embedded platform spec won't take all that long either.)
* Don't call it a "bare metal" or "non-Linux" spec, just "embedded"
(to span a range of hardware/software environments)
Why do we want to include bare-metal ? There won't be any software compatibility between bare-metal software applications. Why do they need to comply with a specification that is not useful to them ? * Practically speaking any Embedded platform spec is primarily of
forward-looking value - for new designs to conform to
- Focus on Embedded-2022 spec
- No Embedded-2020 spec (since there is limited compatibility
across today's systems)
Agreed. There is no standard implementation between existing platforms. * Can only standardize a limited set of basics (given the wide
variety and needs of embedded systems):
- Require RVM22 (with no turning of any optional items into
required items)
+ Feedback to RVM22 definition group about any needed finer-
granularity arch extension breakdowns?
* E.g. mul without div?
* E.g. just parts of S-mode if S-mode supported?
* Wrt the many WARL options in M-mode and S-mode Priv
specs, any required values?
Do we need break the spec RVM22 in individual ISA chunks ? RVM22 can just say RV32I/RV64I is mandatory. Every other extension is optional.
- Require "CLIC and/or PLIC"
+ CLIC from Fast Interrupts TG; need to create a "standard"
PLIC spec
We need to standardize PLIC for Linux-2022 platform specification as well.
- Require CLINT (or rough equivalent)
+ Or require "CLINT or CLIC" if CLIC includes CLINT
functionality (for timer and s/w interrupts)?
+ Need to create a "standard" CLINT spec
- EABI and/or other ABIs as options? Maybe not of value.
- Minimum PMP config (if optionally implemented)
+ This is an example of the above item about WARL options in
the Priv spec
- ???
Greg
-- Regards, Atish
|
|
|
We also need to keep in mind what the marketing names will be for these platform specs - because ultimately that is what most people (outside of this group) will be using. Which probably means names that are at least somewhat self-descriptive (versus an acronym or jumble of letters and numbers).
Greg
On Tue, 2021-02-02 at 19:33 +0100, Philipp Tomsich wrote:
> Linux-2022 is just working title... and we expect the final name to
> be more neutral.
> Calling it “rich OS” didn’t really work to convey the direction to
> the audience.
>
I agree. I am also not sure calling embedded-2022 is a good idea
either. That may confuse outside folks to think that it is meant for
embedded Linux. Al had a better suggestion about the naming.
The specification can be called as Operating System platform
specification (OSPS).
How about this ?
OSPS2022-L0 - targets micro-controllers booting RTOS (zephyr, FreeRTOS
etc)
OSPS2022-L1 - targets hardware capable of booting rich OS such as
Unix/Windows
We will never have more than two levels but each specification will
evolve at 2 years cadence & different version numbers. For example:
The next version of the specifications will be called
OSPS2024-L0 & OSPS2021-L1
Any incremental updates will be just have a minor number versioning.
> The Linux name was chosen to have concepts such from distros to
> building from source in scope... we’ve always tried to be vocal that
> this platform needs to address at least the *BSD variants and
> (possibly) rich RTOSes.
>
> In the end, a name will just be a name.
> At this early stage, the working title needs to help focus us on
> real-world use cases and challenges...
>
> Cheers,
> Philipp.
>
> On Tue 2. Feb 2021 at 19:15, Jonathan Behrens <behrensj@...>
> wrote:
> > Is there an assumption that the only OS kernels claiming
> > compliance with Linux-2022 will actually be versions of the Linux
> > kernel? Given the name, it seems like it would be kind of awkward
> > for a competitor to claim that
> >
> > Jonathan
> >
> > On Tue, Feb 2, 2021 at 12:57 PM Alistair Francis via
> > lists.riscv.org <alistair.francis=wdc.com@...> wrote:
> >
> > > On Tue, 2021-02-02 at 18:08 +0100, Philipp Tomsich wrote:
> > > > Greg & Richard,
> > > >
> > > > On Tue, Feb 2, 2021 at 5:47 PM Greg Favor
> > > <gfavor@...>
> > > > wrote:
> > > > > On Tue, Feb 2, 2021 at 12:31 AM
> > > <Richard.Newell@...>
> > > > > wrote:
> > > > > > Hi Greg, et al;
> > > > > >
> > > > > > We expect Krypto Scalar specification to be ratified this
> > > year.
> > > > > > It is a lightweight extension designed especially for
> > > embedded
> > > > > > systems. The Krypto TG recommends the “K” extension be at
> > > least
> > > > > > an optional part of the RVx22 profiles.
> > > > > >
> > > > >
> > > > > This definitely falls under the purview of the profile specs,
> > > not
> > > > > the platform specs. I suggest contacting Krste and Mark
> > > about
> > > > > this. The effort to put together the profile specs is just
> > > getting
> > > > > started (but expected to complete in a couple of months).
> > > > >
> > > > > Off-hand I would imagine that this extension _will_ be part
> > > of one
> > > > > or both profiles (and probably as optional).
> > > > >
> > > >
> > > > I would hope that the profiles provide this at least as
> > > optional.
> > >
> > > I'm not clear what we mean here. For the embedded spec all
> > > extensiosn
> > > will be optional, that would include ratified, frozen draft and
> > > vendour
> > > extensions.
> > >
> > > Alistair
> > >
> > > >
> > > > On the platforms side, we will then build (at least for the
> > > Linux-
> > > > 2022 profile) on this by mandating runtime discovery and
> > > support for
> > > > it.
> > > > The details on how this support can/will look are still
> > > sketchy,
> > > > however the following assertions should remain unchanged:
> > > > * OS kernels claiming compliance with Linux-2022 will have a
> > > > discovery mechanism (details are TBD; might be as simple as a
> > > > bootloader passing in a flag via the DTB) to detect if K-
> > > support is
> > > > present in hardware.
> > > > * OS kernels claiming compliance with Linux-2022 will expose
> > > the
> > > > availability of K-instructions to userspace applications (e.g.
> > > auxval
> > > > or hwcaps).
> > > > * * OS kernels claiming compliance with Linux-2022 will be
> > > able to
> > > > determine (from an ELF binary) if it contains K-instructions or
> > > not —
> > > > and will only execute code requiring K-instructions if support
> > > is
> > > > present.
> > > > In addition, we'd like to see some adoption of crypto
> > > instructions
> > > > for the benefit of users:
> > > > * * OS kernels will be encouraged to make use of K-
> > > instructions for
> > > > crypto operations in the kernel (e.g. networking-related).
> > > > * OS distributions will be encouraged to provide optimized
> > > support
> > > > (ifunc, additional DSOs) using K-instructions for crypto
> > > operations
> > > > in userspace (e.g. in OpenSSL).
> > > > If the "will be encouraged" will be a non-binding
> > > recommendation or
> > > > if we will add this to an additional "package" (that
> > > implementations
> > > > can claim conformance to), is to be seen and should become
> > > clearer by
> > > > April.
> > > >
> > > > Philipp.
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
>
--
Regards,
Atish
|
|
|
Alistair Francis <alistair.francis@...>
On Tue, 2021-02-02 at 19:17 +0000, Atish Patra wrote: On Mon, 2021-02-01 at 21:59 -0800, Greg Favor wrote:
The following tries to capture and summarize what was discussed in
today's meeting wrt what may be called the Embedded platform spec
(versus the Linux platform spec). I know I have missed some things
and gotten some things a bit wrong, so feel free to correct and add
on to this. I also threw in a couple of narrower,
detailed questions. Thanks Greg.
The point of this is to start email discussion and filling out of
this high-level summary without waiting til the next meeting -
especially from the people that are more knowledgeable about
embedded
systems and what can be standardized and what would be of value to
standardize. Hopefully, since this spec is limited in what can be
usefully standardized, this can be pushed forward in parallel with
the bigger efforts towards fleshing out the framework for the
Linux-
2020/2022 platform spec(s) - especially by people interested in
this
spec. (Put differently, we can't afford to only make progress at
the
rate of one hour a week. And we need to parallelize the two
platform
efforts. Then the biweekly meetings can be sync-up points and
discussion of key issues. And hopefully the basics of a draft
Embedded platform spec won't take all that long either.)
* Don't call it a "bare metal" or "non-Linux" spec, just
"embedded"
(to span a range of hardware/software environments)
Why do we want to include bare-metal ? There won't be any software
compatibility between bare-metal software applications. Why do they
need to comply with a specification that is not useful to them ? There is still a desire to maintain source comparability. As well as that, vendous don't make "RTOS" SoCs. They make SoCs targetting embedded, which can run an RTOS, embedded OS or just custom code. The embedded spec should target everything from handwritten assembly to a full blown embedded OS. In this case embedded OS is something without an MMU.
* Practically speaking any Embedded platform spec is primarily of
forward-looking value - for new designs to conform to
- Focus on Embedded-2022 spec
- No Embedded-2020 spec (since there is limited compatibility
across today's systems)
Agreed. There is no standard implementation between existing
platforms.
+1
* Can only standardize a limited set of basics (given the wide
variety and needs of embedded systems):
- Require RVM22 (with no turning of any optional items into
required items)
+ Feedback to RVM22 definition group about any needed finer-
granularity arch extension breakdowns?
* E.g. mul without div?
* E.g. just parts of S-mode if S-mode supported?
* Wrt the many WARL options in M-mode and S-mode Priv
specs, any required values?
Do we need break the spec RVM22 in individual ISA chunks ?
RVM22 can just say RV32I/RV64I is mandatory. Every other extension is
optional.
Agreed. I think that's the best bet. There was some talk of a optional matrix. For example "IF the platform has implemented M and U mode then at least 4 PMP regions should exist". Thinking about that more I don't think we should do that. I don't think it gives software any benefits and it just locks in vendors. There might be a very small number of these, but overall the best bet seems to be just RV32/64I and whatever else the vendor wants. Alistair
- Require "CLIC and/or PLIC"
+ CLIC from Fast Interrupts TG; need to create a "standard"
PLIC spec
We need to standardize PLIC for Linux-2022 platform specification as
well.
- Require CLINT (or rough equivalent)
+ Or require "CLINT or CLIC" if CLIC includes CLINT
functionality (for timer and s/w interrupts)?
+ Need to create a "standard" CLINT spec
- EABI and/or other ABIs as options? Maybe not of value.
- Minimum PMP config (if optionally implemented)
+ This is an example of the above item about WARL options in
the Priv spec
- ???
Greg
--
Regards,
Atish
|
|
|
mark
that is a good point.
I suggest the platform group spend a little time figuring out the equivalence classes. We can eventually have more than two profiles but don't want dozens of standard profiles.
Mark
On Tue, Feb 2, 2021 at 10:15 AM Jonathan Behrens < behrensj@...> wrote: Is there an assumption that the only OS kernels claiming compliance with Linux-2022 will actually be versions of the Linux kernel? Given the name, it seems like it would be kind of awkward for a competitor to claim that
Jonathan
On Tue, 2021-02-02 at 18:08 +0100, Philipp Tomsich wrote:
> Greg & Richard,
>
> On Tue, Feb 2, 2021 at 5:47 PM Greg Favor <gfavor@...>
> wrote:
> > On Tue, Feb 2, 2021 at 12:31 AM <Richard.Newell@...>
> > wrote:
> > > Hi Greg, et al;
> > >
> > > We expect Krypto Scalar specification to be ratified this year.
> > > It is a lightweight extension designed especially for embedded
> > > systems. The Krypto TG recommends the “K” extension be at least
> > > an optional part of the RVx22 profiles.
> > >
> >
> > This definitely falls under the purview of the profile specs, not
> > the platform specs. I suggest contacting Krste and Mark about
> > this. The effort to put together the profile specs is just getting
> > started (but expected to complete in a couple of months).
> >
> > Off-hand I would imagine that this extension _will_ be part of one
> > or both profiles (and probably as optional).
> >
>
> I would hope that the profiles provide this at least as optional.
I'm not clear what we mean here. For the embedded spec all extensiosn
will be optional, that would include ratified, frozen draft and vendour
extensions.
Alistair
>
> On the platforms side, we will then build (at least for the Linux-
> 2022 profile) on this by mandating runtime discovery and support for
> it.
> The details on how this support can/will look are still sketchy,
> however the following assertions should remain unchanged:
> * OS kernels claiming compliance with Linux-2022 will have a
> discovery mechanism (details are TBD; might be as simple as a
> bootloader passing in a flag via the DTB) to detect if K-support is
> present in hardware.
> * OS kernels claiming compliance with Linux-2022 will expose the
> availability of K-instructions to userspace applications (e.g. auxval
> or hwcaps).
> * * OS kernels claiming compliance with Linux-2022 will be able to
> determine (from an ELF binary) if it contains K-instructions or not —
> and will only execute code requiring K-instructions if support is
> present.
> In addition, we'd like to see some adoption of crypto instructions
> for the benefit of users:
> * * OS kernels will be encouraged to make use of K-instructions for
> crypto operations in the kernel (e.g. networking-related).
> * OS distributions will be encouraged to provide optimized support
> (ifunc, additional DSOs) using K-instructions for crypto operations
> in userspace (e.g. in OpenSSL).
> If the "will be encouraged" will be a non-binding recommendation or
> if we will add this to an additional "package" (that implementations
> can claim conformance to), is to be seen and should become clearer by
> April.
>
> Philipp.
>
|
|
|
> - Require RVM22 (with no turning of any optional items into
> required items)
> + Feedback to RVM22 definition group about any needed finer-
> granularity arch extension breakdowns?
> * E.g. mul without div?
> * E.g. just parts of S-mode if S-mode supported?
> * Wrt the many WARL options in M-mode and S-mode Priv
> specs, any required values?
>
Do we need break the spec RVM22 in individual ISA chunks ?
RVM22 can just say RV32I/RV64I is mandatory. Every other extension is
optional.
A key representative from this group needs to be selected to become part of the RVM profile definition discussions - to provide exactly this sort of input.
Greg
|
|
|
