|
Hi,
The policy document certainly seems to be addressing things from a user's perspective: "From a user perspective, binary operating systems distributions (such as the various Linux distributions) should be easily movable between different hardware."
This makes sense, but it's important to point out that this is targeted for Supervisor level and up. However, my reading is that many things are included in the platform spec that are targeting mandates for different privilege levels which isn't clear to me how this platform is expected to be adhered to.
My assessment is that this platform spec is written and geared towards the equivalent of an OEM or system integrator. There, they control the firmware and what is being implemented. However, that approach assumes a particular market. i.e. OEMs selling systems to end users. Is that the expectation? And would then OEMs dictate to the risc-v implementers what they should create? If this is the intended market I think the platform spec should be explicit in the assumptions it's making in how systems are packaged and provided.
Thanks for the help in understanding scoping of intent. It's very murky to me in how this spec is intended to play out.
-Aaron
|
|
|
Jonathan Behrens <behrensj@...>
Other people can probably jump in with the official charter, but I interpret the platform spec to be defining the interfaces between all M-mode and S-mode software, plus defining any hardware interfaces they can rely on. The idea being that if you are implementing an OS or M-mode firmware or whatever, you know both what is expected of you and what you can expect from the system.
This also partially answers your other email. The reason certain hardware devices and features are required is so software can be written assuming they’ll be present.
Jonathan
Hi,
The policy document certainly seems to be addressing things from a user's perspective: "From a user perspective, binary operating systems distributions (such as the various Linux distributions) should be easily movable between different hardware."
This makes sense, but it's important to point out that this is targeted for Supervisor level and up. However, my reading is that many things are included in the platform spec that are targeting mandates for different privilege levels which isn't clear to me how this platform is expected to be adhered to.
My assessment is that this platform spec is written and geared towards the equivalent of an OEM or system integrator. There, they control the firmware and what is being implemented. However, that approach assumes a particular market. i.e. OEMs selling systems to end users. Is that the expectation? And would then OEMs dictate to the risc-v implementers what they should create? If this is the intended market I think the platform spec should be explicit in the assumptions it's making in how systems are packaged and provided.
Thanks for the help in understanding scoping of intent. It's very murky to me in how this spec is intended to play out.
-Aaron
|
|
|
Kumar Sankaran
Agree with what Jonathan has said below. The platform spec provides a complete set of hardware and software requirements for a platform. In the case of software, the platform spec mandates requirements that software running in M-mode or S-mode or hypervisor mode need to adhere to in order to claim compatibility with that particular platform. Also, the platform spec provides a “minimal” set of required functionality at the hardware and software level for platforms to claim compatibility. It does not take any particular stance on whether an OEM or a system integrator were to build the platform or whether a silicon vendor releases firmware for their reference platform. No such assumptions are made. All we are mandating in software are the requirements at any privilege level. The platform spec however adds extensions for specific target markets like “server”. These extension specific requirements cater to that particular market segment. The introduction Section 1 of the spec provides some more detail regarding this. Hope this answers your questions. Regards Kumar
From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Jonathan Behrens
Sent: Tuesday, October 12, 2021 3:19 PM
To: adurbin@...
Cc: tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] Platform Spec General Feedback Other people can probably jump in with the official charter, but I interpret the platform spec to be defining the interfaces between all M-mode and S-mode software, plus defining any hardware interfaces they can rely on. The idea being that if you are implementing an OS or M-mode firmware or whatever, you know both what is expected of you and what you can expect from the system. This also partially answers your other email. The reason certain hardware devices and features are required is so software can be written assuming they’ll be present. Hi, The policy document certainly seems to be addressing things from a user's perspective: "From a user perspective, binary operating systems distributions (such as the various Linux distributions) should be easily movable between different hardware." This makes sense, but it's important to point out that this is targeted for Supervisor level and up. However, my reading is that many things are included in the platform spec that are targeting mandates for different privilege levels which isn't clear to me how this platform is expected to be adhered to. My assessment is that this platform spec is written and geared towards the equivalent of an OEM or system integrator. There, they control the firmware and what is being implemented. However, that approach assumes a particular market. i.e. OEMs selling systems to end users. Is that the expectation? And would then OEMs dictate to the risc-v implementers what they should create? If this is the intended market I think the platform spec should be explicit in the assumptions it's making in how systems are packaged and provided. Thanks for the help in understanding scoping of intent. It's very murky to me in how this spec is intended to play out.
|
|
|
On Tue, Oct 12, 2021 at 4:37 PM Kumar Sankaran < ksankaran@...> wrote: Agree with what Jonathan has said below. The platform spec provides a complete set of hardware and software requirements for a platform. In the case of software, the platform spec mandates requirements that software running in M-mode or S-mode or hypervisor mode need to adhere to in order to claim compatibility with that particular platform. Also, the platform spec provides a “minimal” set of required functionality at the hardware and software level for platforms to claim compatibility. It does not take any particular stance on whether an OEM or a system integrator were to build the platform or whether a silicon vendor releases firmware for their reference platform. No such assumptions are made. All we are mandating in software are the requirements at any privilege level. The platform spec however adds extensions for specific target markets like “server”. These extension specific requirements cater to that particular market segment. The introduction Section 1 of the spec provides some more detail regarding this.
Thanks Jonathan on Kumar. I understand the thrust of the intent, but it feels like the platform spec may be overreaching in what it's trying to accomplish. The spec seems to be presupposing what is best for a "user" or "customer" without defining those terms or what entity it is benefing.
Qs: 1. Who is the "user" or "customer" ? 2. What markets is this platform spec thinking it's covering? There are OEM to consumer markets as well as business to business markets. Customer or end-user requirements are diverse, but the platform spec doesn't seem to be acknowledging that aside from assuming 3 sets of product requirements to fit all needs of said market with a very broad brush: OS-A, OS-A with server extension, and OS-M. e.g. How is the platform spec informed for what a "server" needs? That would be dictated by a customer. Do we have a diverse survey of customer needs? And is the resulting platform spec the perfect intersection of those requirements? 3. How are people viewing a product? Is this an OEM product? A product sold only from one vendor to another? Separate system integrator? These questions matter because it provides the necessary scope and purpose for the product specification.
For U-mode software, this is largely covered by the inheriting of profiles. This handles the complications of the toolchain and default flags because they'd be targeting a particular ISA composite. Win-win and also applies to S-mode.
For S-mode software, it makes perfect sense to define expectations for the Supervisor Execution Environment where there is a dependency: SBI spec, e.g., and UEFI interface specifications the kernel may be relying on (add DT and ACPI to that mix). That seems perfectly legitimate since those are being declared as a dependency. Now how a particular platform implements those requirements has no bearing how the kernel behaves because it's adhering to the particular interfaces. However, from a hardware perspective, it's forcing implementations (assuming the goal is that people adhere to the platform spec) to take on hardware implementations that may not fit with a particular product direction/requirements. I don't believe it's appropriate for the platform spec to be making product choices on behalf of people designing products. Is the goal to limit the number of drivers every risc-v product needs in the kernel?
For M-mode software, I think we can all agree that there is inherently implementation defined (there is definitely vendor-specific code in opensbi source: https://github.com/riscv-software-src/opensbi). Moreover, M-mode is pretty large when thinking about the entirety of the boot process. While it's a single mode, it cannot and will not be a unified piece of firmware because of the implementation specific pieces. i.e. there is no binary compatibility by definition. So what purpose does dictating M-mode software (and hardware) serve? We're now out of the realm of declaring dependencies that are interfaces to implementation mandates on behalf of an end-user or customer. What problem is being solved by dictating these machine mode requirements?
Hope this answers your questions. Regards Kumar Other people can probably jump in with the official charter, but I interpret the platform spec to be defining the interfaces between all M-mode and S-mode software, plus defining any hardware interfaces they can rely on. The idea being that if you are implementing an OS or M-mode firmware or whatever, you know both what is expected of you and what you can expect from the system. This also partially answers your other email. The reason certain hardware devices and features are required is so software can be written assuming they’ll be present. Hi, The policy document certainly seems to be addressing things from a user's perspective: "From a user perspective, binary operating systems distributions (such as the various Linux distributions) should be easily movable between different hardware." This makes sense, but it's important to point out that this is targeted for Supervisor level and up. However, my reading is that many things are included in the platform spec that are targeting mandates for different privilege levels which isn't clear to me how this platform is expected to be adhered to. My assessment is that this platform spec is written and geared towards the equivalent of an OEM or system integrator. There, they control the firmware and what is being implemented. However, that approach assumes a particular market. i.e. OEMs selling systems to end users. Is that the expectation? And would then OEMs dictate to the risc-v implementers what they should create? If this is the intended market I think the platform spec should be explicit in the assumptions it's making in how systems are packaged and provided. Thanks for the help in understanding scoping of intent. It's very murky to me in how this spec is intended to play out.
|
|
|
On Tue, Oct 12, 2021 at 7:44 PM Aaron Durbin < adurbin@...> wrote: On Tue, Oct 12, 2021 at 4:37 PM Kumar Sankaran < ksankaran@...> wrote: Also, the platform spec provides a “minimal” set of required functionality at the hardware and software level for platforms to claim compatibility. It does not take any particular stance on whether an OEM or a system integrator were to build the platform or whether a silicon vendor releases firmware for their reference platform. No such assumptions are made. All we are mandating in software are the requirements at any privilege level.
The platform spec however adds extensions for specific target markets like “server”. These extension specific requirements cater to that particular market segment. The introduction Section 1 of the spec provides some more detail regarding this.
Thanks Jonathan on Kumar. I understand the thrust of the intent, but it feels like the platform spec may be overreaching in what it's trying to accomplish. The spec seems to be presupposing what is best for a "user" or "customer" without defining those terms or what entity it is benefing.
Qs: 1. Who is the "user" or "customer" ?
There is not a simple singular answer, i.e. there are a number of answers. The OS-A Base or Basic platform spec caters to a wide range of implementations and audiences that fall under the "rich OS" umbrella (versus RTOS and bare metal embedded environments - which is what the Embedded platform specs target). So it's impractical to provide a specific or narrow answer.
Past that (under the OS-A umbrella) there will be a number of further platform specs for server, automotive, HPC, Windows, Android, etc. that cater to more focused applications categories (and provide more standardization and requirements). While the Base or Basic spec caters to what some might call "Embedded Linux" applications - that have a wider range of needs and don't want to be burdened with having to support a larger set of requirements than what they need. 2. What markets is this platform spec thinking it's covering? There are OEM to consumer markets as well as business to business markets. Customer or end-user requirements are diverse, but the platform spec doesn't seem to be acknowledging that aside from assuming 3 sets of product requirements to fit all needs of said market with a very broad brush: OS-A, OS-A with server extension, and OS-M. e.g. How is the platform spec informed for what a "server" needs? That would be dictated by a customer. Do we have a diverse survey of customer needs? And is the resulting platform spec the perfect intersection of those requirements?
(Btw, it is "M" platforms, not "OS-M" platforms. As mentioned above, these two categories or groups of platform specs cater to very different application realms.)
As I noted, there are expected to be more platform specs; the three mentioned are just the first three (there actually are four - two under M and two under OS-A). The "server" platform spec is analogous to SBSA in the ARM world (which has been supplanted in recent years by a group of standards) and reflects a lot of the learnings from ARM and SBSA when that was developed (and evolved over many years). This spec is being reviewed, among others, by several of the notable Linux distros - which generally have found it to be right along the lines of what they'd like to see. 3. How are people viewing a product? Is this an OEM product? A product sold only from one vendor to another? Separate system integrator? These questions matter because it provides the necessary scope and purpose for the product specification.
There are many "users" of ISA profiles and platform specs - from the hardware, software, and system developer ecosystems. (Keep in mind that both profiles and platforms express requirements on hardware and software people.) For U-mode software, this is largely covered by the inheriting of profiles. This handles the complications of the toolchain and default flags because they'd be targeting a particular ISA composite. Win-win and also applies to S-mode.
Keep in mind that there are M, S, and U ISA profiles under each ISA profile group (e.g. for RVA20 and for RVA22) - although I think you already recognize that. There are also RV32 and RV64 versions of the profiles (although just RV64 for RVA profiles to start with).
For S-mode software, it makes perfect sense to define expectations for the Supervisor Execution Environment where there is a dependency: SBI spec, e.g., and UEFI interface specifications the kernel may be relying on (add DT and ACPI to that mix). That seems perfectly legitimate since those are being declared as a dependency. Now how a particular platform implements those requirements has no bearing how the kernel behaves because it's adhering to the particular interfaces. However, from a hardware perspective, it's forcing implementations (assuming the goal is that people adhere to the platform spec) to take on hardware implementations that may not fit with a particular product direction/requirements. I don't believe it's appropriate for the platform spec to be making product choices on behalf of people designing products. Is the goal to limit the number of drivers every risc-v product needs in the kernel?
This is the tension, for both profiles and platforms, between standardizing and requiring more versus less. Profiles generally narrow down what can and must be done to be compliant (compared to the RV arch specs themselves which tend to allow a lot of flexibility/optionality/WARL). Platforms generally narrow things down even more. And some platforms go even further. There is no one answer that fits all. Hence why there are a number of profiles and there will be a growing number of platforms. Some provide broader umbrellas than others - for better and for worse. For M-mode software, I think we can all agree that there is inherently implementation defined (there is definitely vendor-specific code in opensbi source: https://github.com/riscv-software-src/opensbi). Moreover, M-mode is pretty large when thinking about the entirety of the boot process. While it's a single mode, it cannot and will not be a unified piece of firmware because of the implementation specific pieces. i.e. there is no binary compatibility by definition. So what purpose does dictating M-mode software (and hardware) serve? We're now out of the realm of declaring dependencies that are interfaces to implementation mandates on behalf of an end-user or customer. What problem is being solved by dictating these machine mode requirements?
There certainly are significant parts of M-mode software that will be implementation-specific and can't be fully standardized, and there also are parts that will be standard software (e.g. OpenSBI). Standard M-mode software (just like an OS) needs to know what hardware functionality it can depend on being present. Even implementation-specific M-mode software will still want to have certain standardized components that it can depend on being there that it can make use of. Greg
|
|
|
Kumar Sankaran
Additional comments inline On Tue, Oct 12, 2021 at 8:39 PM Greg Favor <gfavor@...> wrote:
On Tue, Oct 12, 2021 at 7:44 PM Aaron Durbin <adurbin@...> wrote:
On Tue, Oct 12, 2021 at 4:37 PM Kumar Sankaran <ksankaran@...> wrote:
Also, the platform spec provides a “minimal” set of required functionality at the hardware and software level for platforms to claim compatibility. It does not take any particular stance on whether an OEM or a system integrator were to build the platform or whether a silicon vendor releases firmware for their reference platform. No such assumptions are made. All we are mandating in software are the requirements at any privilege level.
The platform spec however adds extensions for specific target markets like “server”. These extension specific requirements cater to that particular market segment. The introduction Section 1 of the spec provides some more detail regarding this.
Thanks Jonathan on Kumar. I understand the thrust of the intent, but it feels like the platform spec may be overreaching in what it's trying to accomplish. The spec seems to be presupposing what is best for a "user" or "customer" without defining those terms or what entity it is benefing.
Qs:
1. Who is the "user" or "customer" ?
There is not a simple singular answer, i.e. there are a number of answers. The OS-A Base or Basic platform spec caters to a wide range of implementations and audiences that fall under the "rich OS" umbrella (versus RTOS and bare metal embedded environments - which is what the Embedded platform specs target). So it's impractical to provide a specific or narrow answer.
Past that (under the OS-A umbrella) there will be a number of further platform specs for server, automotive, HPC, Windows, Android, etc. that cater to more focused applications categories (and provide more standardization and requirements). While the Base or Basic spec caters to what some might call "Embedded Linux" applications - that have a wider range of needs and don't want to be burdened with having to support a larger set of requirements than what they need.
The platform spec does not cater to any particular user or customer. Instead, the platform spec provides a set of hardware and software requirements that all platforms must adhere to in order to ensure compatibility. In terms of target market applicability of where each platform would fit, look at the Introduction Section 1 of the document.
2. What markets is this platform spec thinking it's covering? There are OEM to consumer markets as well as business to business markets. Customer or end-user requirements are diverse, but the platform spec doesn't seem to be acknowledging that aside from assuming 3 sets of product requirements to fit all needs of said market with a very broad brush: OS-A, OS-A with server extension, and OS-M. e.g. How is the platform spec informed for what a "server" needs? That would be dictated by a customer. Do we have a diverse survey of customer needs? And is the resulting platform spec the perfect intersection of those requirements?
(Btw, it is "M" platforms, not "OS-M" platforms. As mentioned above, these two categories or groups of platform specs cater to very different application realms.)
As I noted, there are expected to be more platform specs; the three mentioned are just the first three (there actually are four - two under M and two under OS-A). The "server" platform spec is analogous to SBSA in the ARM world (which has been supplanted in recent years by a group of standards) and reflects a lot of the learnings from ARM and SBSA when that was developed (and evolved over many years). This spec is being reviewed, among others, by several of the notable Linux distros - which generally have found it to be right along the lines of what they'd like to see.
The goal of the platform spec is to come up with the "minimal" set of mandatory features that all platforms must implement in order to be compatible with each other. The goal here is not to create a spec that exhaustively covers every customer requirement or every market segment requirement for that particular target market.
3. How are people viewing a product? Is this an OEM product? A product sold only from one vendor to another? Separate system integrator? These questions matter because it provides the necessary scope and purpose for the product specification.
There are many "users" of ISA profiles and platform specs - from the hardware, software, and system developer ecosystems. (Keep in mind that both profiles and platforms express requirements on hardware and software people.)
For U-mode software, this is largely covered by the inheriting of profiles. This handles the complications of the toolchain and default flags because they'd be targeting a particular ISA composite. Win-win and also applies to S-mode.
Keep in mind that there are M, S, and U ISA profiles under each ISA profile group (e.g. for RVA20 and for RVA22) - although I think you already recognize that. There are also RV32 and RV64 versions of the profiles (although just RV64 for RVA profiles to start with).
For S-mode software, it makes perfect sense to define expectations for the Supervisor Execution Environment where there is a dependency: SBI spec, e.g., and UEFI interface specifications the kernel may be relying on (add DT and ACPI to that mix). That seems perfectly legitimate since those are being declared as a dependency. Now how a particular platform implements those requirements has no bearing how the kernel behaves because it's adhering to the particular interfaces. However, from a hardware perspective, it's forcing implementations (assuming the goal is that people adhere to the platform spec) to take on hardware implementations that may not fit with a particular product direction/requirements. I don't believe it's appropriate for the platform spec to be making product choices on behalf of people designing products. Is the goal to limit the number of drivers every risc-v product needs in the kernel?
This is the tension, for both profiles and platforms, between standardizing and requiring more versus less. Profiles generally narrow down what can and must be done to be compliant (compared to the RV arch specs themselves which tend to allow a lot of flexibility/optionality/WARL). Platforms generally narrow things down even more. And some platforms go even further. There is no one answer that fits all. Hence why there are a number of profiles and there will be a growing number of platforms. Some provide broader umbrellas than others - for better and for worse.
The platform spec is only a specification provided for platforms to use as a governance. It applies to all end-products that need the RISC-V platform compatibility branding. Regarding the Linux kernel, the platform spec mandates some bare minimal drivers that need to be supported. For example, the UART 16550 support or the AIA interrupt support for OS-A server. These are mandatory and must be supported in the hardware. Beyond these mandatory requirements, platforms are free to implement everything else that is needed for their own specific use cases. So the Linux kernel will have everything else that is currently there. The spec mandates some needs for compatibility.
For M-mode software, I think we can all agree that there is inherently implementation defined (there is definitely vendor-specific code in opensbi source: https://github.com/riscv-software-src/opensbi). Moreover, M-mode is pretty large when thinking about the entirety of the boot process. While it's a single mode, it cannot and will not be a unified piece of firmware because of the implementation specific pieces. i.e. there is no binary compatibility by definition. So what purpose does dictating M-mode software (and hardware) serve? We're now out of the realm of declaring dependencies that are interfaces to implementation mandates on behalf of an end-user or customer. What problem is being solved by dictating these machine mode requirements?
There certainly are significant parts of M-mode software that will be implementation-specific and can't be fully standardized, and there also are parts that will be standard software (e.g. OpenSBI). Standard M-mode software (just like an OS) needs to know what hardware functionality it can depend on being present. Even implementation-specific M-mode software will still want to have certain standardized components that it can depend on being there that it can make use of.
Greg
-- Regards Kumar
|
|
|
I have been attending the platform spec meetings regularly since inception,
and it seems to me that questions similar to this are frequently brought
up. The typical response, as here, is to provide an answer directly to the
individual that asked the question, sometimes with varying degrees of
detail. Perhaps it would be more productive to take this feedback and
address the specification and policy documents so that these questions
don't have to be repeatedly answered, and, more importantly, to refine the
specification to be more comprehensible to the wider community.
// darius
toggle quoted message
Show quoted text
On Tue, Oct 12, 2021 at 03:37:17PM -0700, Kumar Sankaran wrote: Agree with what Jonathan has said below.
The platform spec provides a complete set of hardware and software
requirements for a platform. In the case of software, the platform spec
mandates requirements that software running in M-mode or S-mode or
hypervisor mode need to adhere to in order to claim compatibility with that
particular platform.
Also, the platform spec provides a “minimal” set of required functionality
at the hardware and software level for platforms to claim compatibility. It
does not take any particular stance on whether an OEM or a system
integrator were to build the platform or whether a silicon vendor releases
firmware for their reference platform. No such assumptions are made. All we
are mandating in software are the requirements at any privilege level.
The platform spec however adds extensions for specific target markets like
“server”. These extension specific requirements cater to that particular
market segment. The introduction Section 1 of the spec provides some more
detail regarding this.
Hope this answers your questions.
Regards
Kumar
*From:* tech-unixplatformspec@... <
tech-unixplatformspec@...> *On Behalf Of *Jonathan Behrens
*Sent:* Tuesday, October 12, 2021 3:19 PM
*To:* adurbin@...
*Cc:* tech-unixplatformspec@...
*Subject:* Re: [RISC-V] [tech-unixplatformspec] Platform Spec General
Feedback
Other people can probably jump in with the official charter, but I
interpret the platform spec to be defining the interfaces between all
M-mode and S-mode software, plus defining any hardware interfaces they can
rely on. The idea being that if you are implementing an OS or M-mode
firmware or whatever, you know both what is expected of you and what you
can expect from the system.
This also partially answers your other email. The reason certain hardware
devices and features are required is so software can be written assuming
they’ll be present.
Jonathan
On Tue, Oct 12, 2021 at 5:03 PM Aaron Durbin via lists.riscv.org <adurbin=
rivosinc.com@...> wrote:
Hi,
I went through the policy document (
https://docs.google.com/document/d/1U5qLoztZpCRSnw2s8tx4rB0SFPMQ27Svrr9jWRsOziY)
as well as the platform spec itself (
https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc
).
The policy document certainly seems to be addressing things from a user's
perspective:
"From a user perspective, binary operating systems distributions (such as
the various Linux distributions) should be easily movable between different
hardware."
This makes sense, but it's important to point out that this is targeted for
Supervisor level and up. However, my reading is that many things are
included in the platform spec that are targeting mandates for different
privilege levels which isn't clear to me how this platform is expected to
be adhered to.
My assessment is that this platform spec is written and geared towards the
equivalent of an OEM or system integrator. There, they control the firmware
and what is being implemented. However, that approach assumes a particular
market. i.e. OEMs selling systems to end users. Is that the expectation?
And would then OEMs dictate to the risc-v implementers what they should
create? If this is the intended market I think the platform spec should be
explicit in the assumptions it's making in how systems are packaged and
provided.
Thanks for the help in understanding scoping of intent. It's very murky to
me in how this spec is intended to play out.
-Aaron
|
|
|
mark
Aaron,
thank you for your thoughtful email.
I will let the sw and platform committees weigh in but also note we have an inbound product management SIG that is responsible for driving things from the industries perspective and it should feed i to answering some of your questions. It is called the industries SIG and led by pen li of sifive. It has been on hiatus and is just restarting.
like many things at risc-v we want to accomplish more than our resources can bear and not everything is developed like it might be in a corporation. the TSC has a goal of driving the priorities top down coordinating with any bottoms up areas. this work is just beginning and we still have table stakes specs to develop or complete.
so please be patient with us and feel free to help drive the agenda and spec development and help us make the processes and what we work on better.
Mark -------- sent from a mobile device. please forgive any typos.
On Oct 12, 2021, at 7:44 PM, Aaron Durbin <adurbin@...> wrote:
On Tue, Oct 12, 2021 at 4:37 PM Kumar Sankaran < ksankaran@...> wrote: Agree with what Jonathan has said below. The platform spec provides a complete set of hardware and software requirements for a platform. In the case of software, the platform spec mandates requirements that software running in M-mode or S-mode or hypervisor mode need to adhere to in order to claim compatibility with that particular platform. Also, the platform spec provides a “minimal” set of required functionality at the hardware and software level for platforms to claim compatibility. It does not take any particular stance on whether an OEM or a system integrator were to build the platform or whether a silicon vendor releases firmware for their reference platform. No such assumptions are made. All we are mandating in software are the requirements at any privilege level. The platform spec however adds extensions for specific target markets like “server”. These extension specific requirements cater to that particular market segment. The introduction Section 1 of the spec provides some more detail regarding this.
Thanks Jonathan on Kumar. I understand the thrust of the intent, but it feels like the platform spec may be overreaching in what it's trying to accomplish. The spec seems to be presupposing what is best for a "user" or "customer" without defining those terms or what entity it is benefing.
Qs: 1. Who is the "user" or "customer" ? 2. What markets is this platform spec thinking it's covering? There are OEM to consumer markets as well as business to business markets. Customer or end-user requirements are diverse, but the platform spec doesn't seem to be acknowledging that aside from assuming 3 sets of product requirements to fit all needs of said market with a very broad brush: OS-A, OS-A with server extension, and OS-M. e.g. How is the platform spec informed for what a "server" needs? That would be dictated by a customer. Do we have a diverse survey of customer needs? And is the resulting platform spec the perfect intersection of those requirements? 3. How are people viewing a product? Is this an OEM product? A product sold only from one vendor to another? Separate system integrator? These questions matter because it provides the necessary scope and purpose for the product specification.
For U-mode software, this is largely covered by the inheriting of profiles. This handles the complications of the toolchain and default flags because they'd be targeting a particular ISA composite. Win-win and also applies to S-mode.
For S-mode software, it makes perfect sense to define expectations for the Supervisor Execution Environment where there is a dependency: SBI spec, e.g., and UEFI interface specifications the kernel may be relying on (add DT and ACPI to that mix). That seems perfectly legitimate since those are being declared as a dependency. Now how a particular platform implements those requirements has no bearing how the kernel behaves because it's adhering to the particular interfaces. However, from a hardware perspective, it's forcing implementations (assuming the goal is that people adhere to the platform spec) to take on hardware implementations that may not fit with a particular product direction/requirements. I don't believe it's appropriate for the platform spec to be making product choices on behalf of people designing products. Is the goal to limit the number of drivers every risc-v product needs in the kernel?
For M-mode software, I think we can all agree that there is inherently implementation defined (there is definitely vendor-specific code in opensbi source: https://github.com/riscv-software-src/opensbi). Moreover, M-mode is pretty large when thinking about the entirety of the boot process. While it's a single mode, it cannot and will not be a unified piece of firmware because of the implementation specific pieces. i.e. there is no binary compatibility by definition. So what purpose does dictating M-mode software (and hardware) serve? We're now out of the realm of declaring dependencies that are interfaces to implementation mandates on behalf of an end-user or customer. What problem is being solved by dictating these machine mode requirements?
Hope this answers your questions. Regards Kumar Other people can probably jump in with the official charter, but I interpret the platform spec to be defining the interfaces between all M-mode and S-mode software, plus defining any hardware interfaces they can rely on. The idea being that if you are implementing an OS or M-mode firmware or whatever, you know both what is expected of you and what you can expect from the system. This also partially answers your other email. The reason certain hardware devices and features are required is so software can be written assuming they’ll be present. Hi, The policy document certainly seems to be addressing things from a user's perspective: "From a user perspective, binary operating systems distributions (such as the various Linux distributions) should be easily movable between different hardware." This makes sense, but it's important to point out that this is targeted for Supervisor level and up. However, my reading is that many things are included in the platform spec that are targeting mandates for different privilege levels which isn't clear to me how this platform is expected to be adhered to. My assessment is that this platform spec is written and geared towards the equivalent of an OEM or system integrator. There, they control the firmware and what is being implemented. However, that approach assumes a particular market. i.e. OEMs selling systems to end users. Is that the expectation? And would then OEMs dictate to the risc-v implementers what they should create? If this is the intended market I think the platform spec should be explicit in the assumptions it's making in how systems are packaged and provided. Thanks for the help in understanding scoping of intent. It's very murky to me in how this spec is intended to play out.
|
|
|
mark
First, thank you for your comments. I agree.
Sometimes we iterate because we don't totally understand the scope of the issue. I suggest that when you make a comment or raise an issue, please propose alternate language that addresses your issue. This will help the folks writing the policies (they are doing a lot of work and can use any help you can provide) and specs and stands as a good record of what would remediate the issue and is the best way for us to track issues (email is good for discussion but these mechanisms force us to resolve them more reliably). If you can't, then include your proposed change of language in email.
We are a continuous improvement organization and don't claim to get things right but we are always open to input and request you help us make things better.
Mark
On Wed, Oct 13, 2021 at 3:51 AM Darius Rad < darius@...> wrote: I have been attending the platform spec meetings regularly since inception,
and it seems to me that questions similar to this are frequently brought
up. The typical response, as here, is to provide an answer directly to the
individual that asked the question, sometimes with varying degrees of
detail. Perhaps it would be more productive to take this feedback and
address the specification and policy documents so that these questions
don't have to be repeatedly answered, and, more importantly, to refine the
specification to be more comprehensible to the wider community.
// darius
On Tue, Oct 12, 2021 at 03:37:17PM -0700, Kumar Sankaran wrote:
> Agree with what Jonathan has said below.
>
> The platform spec provides a complete set of hardware and software
> requirements for a platform. In the case of software, the platform spec
> mandates requirements that software running in M-mode or S-mode or
> hypervisor mode need to adhere to in order to claim compatibility with that
> particular platform.
>
> Also, the platform spec provides a “minimal” set of required functionality
> at the hardware and software level for platforms to claim compatibility. It
> does not take any particular stance on whether an OEM or a system
> integrator were to build the platform or whether a silicon vendor releases
> firmware for their reference platform. No such assumptions are made. All we
> are mandating in software are the requirements at any privilege level.
>
> The platform spec however adds extensions for specific target markets like
> “server”. These extension specific requirements cater to that particular
> market segment. The introduction Section 1 of the spec provides some more
> detail regarding this.
>
>
>
> Hope this answers your questions.
>
>
>
> Regards
>
> Kumar
>
> *From:* tech-unixplatformspec@... <
> tech-unixplatformspec@...> *On Behalf Of *Jonathan Behrens
> *Sent:* Tuesday, October 12, 2021 3:19 PM
> *To:* adurbin@...
> *Cc:* tech-unixplatformspec@...
> *Subject:* Re: [RISC-V] [tech-unixplatformspec] Platform Spec General
> Feedback
>
>
>
> Other people can probably jump in with the official charter, but I
> interpret the platform spec to be defining the interfaces between all
> M-mode and S-mode software, plus defining any hardware interfaces they can
> rely on. The idea being that if you are implementing an OS or M-mode
> firmware or whatever, you know both what is expected of you and what you
> can expect from the system.
>
>
>
> This also partially answers your other email. The reason certain hardware
> devices and features are required is so software can be written assuming
> they’ll be present.
>
>
>
> Jonathan
>
>
>
>
>
> On Tue, Oct 12, 2021 at 5:03 PM Aaron Durbin via lists.riscv.org <adurbin=
> rivosinc.com@...> wrote:
>
> Hi,
>
>
>
> I went through the policy document (
> https://docs.google.com/document/d/1U5qLoztZpCRSnw2s8tx4rB0SFPMQ27Svrr9jWRsOziY)
> as well as the platform spec itself (
> https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc
> ).
>
>
>
> The policy document certainly seems to be addressing things from a user's
> perspective:
>
> "From a user perspective, binary operating systems distributions (such as
> the various Linux distributions) should be easily movable between different
> hardware."
>
>
>
> This makes sense, but it's important to point out that this is targeted for
> Supervisor level and up. However, my reading is that many things are
> included in the platform spec that are targeting mandates for different
> privilege levels which isn't clear to me how this platform is expected to
> be adhered to.
>
>
>
> My assessment is that this platform spec is written and geared towards the
> equivalent of an OEM or system integrator. There, they control the firmware
> and what is being implemented. However, that approach assumes a particular
> market. i.e. OEMs selling systems to end users. Is that the expectation?
> And would then OEMs dictate to the risc-v implementers what they should
> create? If this is the intended market I think the platform spec should be
> explicit in the assumptions it's making in how systems are packaged and
> provided.
>
>
>
> Thanks for the help in understanding scoping of intent. It's very murky to
> me in how this spec is intended to play out.
>
>
>
> -Aaron
>
>
>
>
>
>
>
|
|
|
On Tue, Oct 12, 2021 at 9:39 PM Greg Favor < gfavor@...> wrote: On Tue, Oct 12, 2021 at 7:44 PM Aaron Durbin < adurbin@...> wrote: On Tue, Oct 12, 2021 at 4:37 PM Kumar Sankaran < ksankaran@...> wrote: Also, the platform spec provides a “minimal” set of required functionality at the hardware and software level for platforms to claim compatibility. It does not take any particular stance on whether an OEM or a system integrator were to build the platform or whether a silicon vendor releases firmware for their reference platform. No such assumptions are made. All we are mandating in software are the requirements at any privilege level.
The platform spec however adds extensions for specific target markets like “server”. These extension specific requirements cater to that particular market segment. The introduction Section 1 of the spec provides some more detail regarding this.
Thanks Jonathan on Kumar. I understand the thrust of the intent, but it feels like the platform spec may be overreaching in what it's trying to accomplish. The spec seems to be presupposing what is best for a "user" or "customer" without defining those terms or what entity it is benefing.
Qs: 1. Who is the "user" or "customer" ?
There is not a simple singular answer, i.e. there are a number of answers. The OS-A Base or Basic platform spec caters to a wide range of implementations and audiences that fall under the "rich OS" umbrella (versus RTOS and bare metal embedded environments - which is what the Embedded platform specs target). So it's impractical to provide a specific or narrow answer.
Past that (under the OS-A umbrella) there will be a number of further platform specs for server, automotive, HPC, Windows, Android, etc. that cater to more focused applications categories (and provide more standardization and requirements). While the Base or Basic spec caters to what some might call "Embedded Linux" applications - that have a wider range of needs and don't want to be burdened with having to support a larger set of requirements than what they need.
Again, I understand that intent. But, what I'm missing is where that diligence was done to declare what is basic. And what is the recourse when someone disagrees with what is deemed basic or minimal for a particular market segment as declared by the platform spec? It be easier to decide if a potential product fits within that predetermined bucket if it was defined. Basically, how inclusive is the platform spec attempting to be on behalf of risc-v implementers?
2. What markets is this platform spec thinking it's covering? There are OEM to consumer markets as well as business to business markets. Customer or end-user requirements are diverse, but the platform spec doesn't seem to be acknowledging that aside from assuming 3 sets of product requirements to fit all needs of said market with a very broad brush: OS-A, OS-A with server extension, and OS-M. e.g. How is the platform spec informed for what a "server" needs? That would be dictated by a customer. Do we have a diverse survey of customer needs? And is the resulting platform spec the perfect intersection of those requirements?
(Btw, it is "M" platforms, not "OS-M" platforms. As mentioned above, these two categories or groups of platform specs cater to very different application realms.)
As I noted, there are expected to be more platform specs; the three mentioned are just the first three (there actually are four - two under M and two under OS-A). The "server" platform spec is analogous to SBSA in the ARM world (which has been supplanted in recent years by a group of standards) and reflects a lot of the learnings from ARM and SBSA when that was developed (and evolved over many years). This spec is being reviewed, among others, by several of the notable Linux distros - which generally have found it to be right along the lines of what they'd like to see.
Please correct me, but it's my understanding that the Linux distros are primarily concerned with S-mode and U-mode; that's always been my experience. They do not represent designers or people working in m-mode. This is the layer separation I was alluding to where I think the platform spec is overreaching. I'm glad they are involved and providing feedback, but they are not fully representative of all components that go into designing a product. 3. How are people viewing a product? Is this an OEM product? A product sold only from one vendor to another? Separate system integrator? These questions matter because it provides the necessary scope and purpose for the product specification.
There are many "users" of ISA profiles and platform specs - from the hardware, software, and system developer ecosystems. (Keep in mind that both profiles and platforms express requirements on hardware and software people.)
That doesn't answer my question about the view of the platform spec that constitutes what a product is in each of the buckets as defined in the platform spec. Yes, I agree, there are requirements on both hw and sw, but there are degrees of requirements that enter in the realm of product definition which I don't think it should be doing. In other words, there's a balance to strike in building an ecosystem and limiting the innovation within an ecosystem because of overreaching requirements. For U-mode software, this is largely covered by the inheriting of profiles. This handles the complications of the toolchain and default flags because they'd be targeting a particular ISA composite. Win-win and also applies to S-mode.
Keep in mind that there are M, S, and U ISA profiles under each ISA profile group (e.g. for RVA20 and for RVA22) - although I think you already recognize that. There are also RV32 and RV64 versions of the profiles (although just RV64 for RVA profiles to start with).
For S-mode software, it makes perfect sense to define expectations for the Supervisor Execution Environment where there is a dependency: SBI spec, e.g., and UEFI interface specifications the kernel may be relying on (add DT and ACPI to that mix). That seems perfectly legitimate since those are being declared as a dependency. Now how a particular platform implements those requirements has no bearing how the kernel behaves because it's adhering to the particular interfaces. However, from a hardware perspective, it's forcing implementations (assuming the goal is that people adhere to the platform spec) to take on hardware implementations that may not fit with a particular product direction/requirements. I don't believe it's appropriate for the platform spec to be making product choices on behalf of people designing products. Is the goal to limit the number of drivers every risc-v product needs in the kernel?
This is the tension, for both profiles and platforms, between standardizing and requiring more versus less. Profiles generally narrow down what can and must be done to be compliant (compared to the RV arch specs themselves which tend to allow a lot of flexibility/optionality/WARL). Platforms generally narrow things down even more. And some platforms go even further. There is no one answer that fits all. Hence why there are a number of profiles and there will be a growing number of platforms. Some provide broader umbrellas than others - for better and for worse.
While I agree there is no one answer, I dispute that the buckets, as outlined in the platform spec, cover even those broad terms in their entirety. As you rightly noted, there is no one answer. Thus, this was why I was asking for definition of products and how those products come to market. What I infer in reading the platform spec is that there are assumptions not stated that constitute a product in such a market segment. For example, what is a "server"? And how would those "servers" be deployed? And designed? For M-mode software, I think we can all agree that there is inherently implementation defined (there is definitely vendor-specific code in opensbi source: https://github.com/riscv-software-src/opensbi). Moreover, M-mode is pretty large when thinking about the entirety of the boot process. While it's a single mode, it cannot and will not be a unified piece of firmware because of the implementation specific pieces. i.e. there is no binary compatibility by definition. So what purpose does dictating M-mode software (and hardware) serve? We're now out of the realm of declaring dependencies that are interfaces to implementation mandates on behalf of an end-user or customer. What problem is being solved by dictating these machine mode requirements?
There certainly are significant parts of M-mode software that will be implementation-specific and can't be fully standardized, and there also are parts that will be standard software (e.g. OpenSBI). Standard M-mode software (just like an OS) needs to know what hardware functionality it can depend on being present. Even implementation-specific M-mode software will still want to have certain standardized components that it can depend on being there that it can make use of.
OpenSBI is inherently different than the SBI spec in that OpenSBI implements SBI spec. The spec is the interface that the S-mode assumes in OS-A. While you may desire the usage of OpenSBI, that doesn't mean it should be mandated. That's an implementers choice, and I suspect many people will decide to go that way. Also, there is not a standard M-mode software that is all encompassing when thinking about the bootflow. I assert it's up to the product designers, OEMs, and manufacturers to decide what is best for their product.
-Aaron
|
|
|
On Wed, Oct 13, 2021 at 12:47 AM Kumar Sankaran < ksankaran@...> wrote: Additional comments inline
On Tue, Oct 12, 2021 at 8:39 PM Greg Favor <gfavor@...> wrote:
>
> On Tue, Oct 12, 2021 at 7:44 PM Aaron Durbin <adurbin@...> wrote:
>>
>> On Tue, Oct 12, 2021 at 4:37 PM Kumar Sankaran <ksankaran@...> wrote:
>>>
>>> Also, the platform spec provides a “minimal” set of required functionality at the hardware and software level for platforms to claim compatibility. It does not take any particular stance on whether an OEM or a system integrator were to build the platform or whether a silicon vendor releases firmware for their reference platform. No such assumptions are made. All we are mandating in software are the requirements at any privilege level.
>>>
>>> The platform spec however adds extensions for specific target markets like “server”. These extension specific requirements cater to that particular market segment. The introduction Section 1 of the spec provides some more detail regarding this.
>>
>>
>> Thanks Jonathan on Kumar. I understand the thrust of the intent, but it feels like the platform spec may be overreaching in what it's trying to accomplish. The spec seems to be presupposing what is best for a "user" or "customer" without defining those terms or what entity it is benefing.
>>
>> Qs:
>> 1. Who is the "user" or "customer" ?
>
>
> There is not a simple singular answer, i.e. there are a number of answers. The OS-A Base or Basic platform spec caters to a wide range of implementations and audiences that fall under the "rich OS" umbrella (versus RTOS and bare metal embedded environments - which is what the Embedded platform specs target). So it's impractical to provide a specific or narrow answer.
>
> Past that (under the OS-A umbrella) there will be a number of further platform specs for server, automotive, HPC, Windows, Android, etc. that cater to more focused applications categories (and provide more standardization and requirements). While the Base or Basic spec caters to what some might call "Embedded Linux" applications - that have a wider range of needs and don't want to be burdened with having to support a larger set of requirements than what they need.
The platform spec does not cater to any particular user or customer.
Instead, the platform spec provides a set of hardware and software
requirements that all platforms must adhere to in order to ensure
compatibility. In terms of target market applicability of where each
platform would fit, look at the Introduction Section 1 of the
document.
Section 1 does not detail the product assumptions; It is an enumeration of the buckets. I agree the intent is to ensure compatibility, but there are degrees of requirements. My critique is that it is too much in certain areas, and I would like to see a better description as to why each requirement is necessary.
>
>>
>> 2. What markets is this platform spec thinking it's covering? There are OEM to consumer markets as well as business to business markets. Customer or end-user requirements are diverse, but the platform spec doesn't seem to be acknowledging that aside from assuming 3 sets of product requirements to fit all needs of said market with a very broad brush: OS-A, OS-A with server extension, and OS-M. e.g. How is the platform spec informed for what a "server" needs? That would be dictated by a customer. Do we have a diverse survey of customer needs? And is the resulting platform spec the perfect intersection of those requirements?
>
>
> (Btw, it is "M" platforms, not "OS-M" platforms. As mentioned above, these two categories or groups of platform specs cater to very different application realms.)
>
> As I noted, there are expected to be more platform specs; the three mentioned are just the first three (there actually are four - two under M and two under OS-A). The "server" platform spec is analogous to SBSA in the ARM world (which has been supplanted in recent years by a group of standards) and reflects a lot of the learnings from ARM and SBSA when that was developed (and evolved over many years). This spec is being reviewed, among others, by several of the notable Linux distros - which generally have found it to be right along the lines of what they'd like to see.
The goal of the platform spec is to come up with the "minimal" set of
mandatory features that all platforms must implement in order to be
compatible with each other. The goal here is not to create a spec that
exhaustively covers every customer requirement or every market segment
requirement for that particular target market.
Given that it can't exhaustively cover every requirement, why are the ones that are in the platform spec there? Under what framework is being used to determine and declare those requirements on behalf of products? And why is this set deemed "minimal"? The platform spec objective, to me, seems overly broad in that it's not clear what set of problems are trying to be head off before they occur.
>
>>
>> 3. How are people viewing a product? Is this an OEM product? A product sold only from one vendor to another? Separate system integrator? These questions matter because it provides the necessary scope and purpose for the product specification.
>
>
> There are many "users" of ISA profiles and platform specs - from the hardware, software, and system developer ecosystems. (Keep in mind that both profiles and platforms express requirements on hardware and software people.)
>
>>
>> For U-mode software, this is largely covered by the inheriting of profiles. This handles the complications of the toolchain and default flags because they'd be targeting a particular ISA composite. Win-win and also applies to S-mode.
>
>
> Keep in mind that there are M, S, and U ISA profiles under each ISA profile group (e.g. for RVA20 and for RVA22) - although I think you already recognize that. There are also RV32 and RV64 versions of the profiles (although just RV64 for RVA profiles to start with).
>
>>
>>
>> For S-mode software, it makes perfect sense to define expectations for the Supervisor Execution Environment where there is a dependency: SBI spec, e.g., and UEFI interface specifications the kernel may be relying on (add DT and ACPI to that mix). That seems perfectly legitimate since those are being declared as a dependency. Now how a particular platform implements those requirements has no bearing how the kernel behaves because it's adhering to the particular interfaces. However, from a hardware perspective, it's forcing implementations (assuming the goal is that people adhere to the platform spec) to take on hardware implementations that may not fit with a particular product direction/requirements. I don't believe it's appropriate for the platform spec to be making product choices on behalf of people designing products. Is the goal to limit the number of drivers every risc-v product needs in the kernel?
>
>
> This is the tension, for both profiles and platforms, between standardizing and requiring more versus less. Profiles generally narrow down what can and must be done to be compliant (compared to the RV arch specs themselves which tend to allow a lot of flexibility/optionality/WARL). Platforms generally narrow things down even more. And some platforms go even further. There is no one answer that fits all. Hence why there are a number of profiles and there will be a growing number of platforms. Some provide broader umbrellas than others - for better and for worse.
The platform spec is only a specification provided for platforms to
use as a governance. It applies to all end-products that need the
RISC-V platform compatibility branding. Regarding the Linux kernel,
the platform spec mandates some bare minimal drivers that need to be
supported. For example, the UART 16550 support or the AIA interrupt
support for OS-A server. These are mandatory and must be supported in
the hardware. Beyond these mandatory requirements, platforms are free
to implement everything else that is needed for their own specific use
cases. So the Linux kernel will have everything else that is currently
there. The spec mandates some needs for compatibility.
Could you please describe where end-products would need the RISC-V platform compatibility branding? I think answering that question answers my questions about the stance of the platform spec w.r.t. product requirements. The spec certainly has an implied opinion how such branding would be used and marketed. How products would market themselves within a certain market segment, etc.
How inclusive is the platform spec attempting to be with respect to end-products? It very much makes requirements that force implementations of certain IP blocks. Your two examples, UART and AIA, are good examples to include. However, as noted in my other email, the platform spec dictates on behalf of the product what combinations of specific IPs *have* to be there. The UART 16550 requirement has no definition of register layout, but the AIA pieces dictate "one or more" in combination with assuming 'wired IRQs' which there's no reasoning described. There are other examples in my technical feedback email.
-Aaron
|
|
|
On Wed, Oct 13, 2021 at 7:32 AM Aaron Durbin < adurbin@...> wrote: Again, I understand that intent. But, what I'm missing is where that diligence was done to declare what is basic. And what is the recourse when someone disagrees with what is deemed basic or minimal for a particular market segment as declared by the platform spec? It be easier to decide if a potential product fits within that predetermined bucket if it was defined. Basically, how inclusive is the platform spec attempting to be on behalf of risc-v implementers?
A minimal platform spec is of corresponding limited value from a standardization and hardware/software interoperability perspective. The M platform does, though tend towards minimal requirements simply because of the enormous range of what "embedded" designs want and don't want to do. The OS-A Base platform tries to strike a balance between what a wide range of implementations/products/markets/etc. want to have and not have. By its nature, it caters to a wide range of products. Even ARM, with SBSA (and its later BSA'sgdidn't try to define what each platform spec was targeting - other than a sentence or two high-level broad description. Please correct me, but it's my understanding that the Linux distros are primarily concerned with S-mode and U-mode; that's always been my experience. They do not represent designers or people working in m-mode. This is the layer separation I was alluding to where I think the platform spec is overreaching. I'm glad they are involved and providing feedback, but they are not fully representative of all components that go into designing a product.
Somewhat like profile specs are not just about U-mode or S-mode, platform specs encompass a complete system (not just what an OS or hypervisor sees) - both hardware-wise and software-wise. ARM SBSA/BSA's provide a good example, generally speaking, of what the ecosystem has demanded of ARM as far as platform standardization and not just OS environment standardization (which includes EL3 and Secure world stuff - roughly analogous to M-mode). That doesn't answer my question about the view of the platform spec that constitutes what a product is in each of the buckets as defined in the platform spec. Yes, I agree, there are requirements on both hw and sw, but there are degrees of requirements that enter in the realm of product definition which I don't think it should be doing. In other words, there's a balance to strike in building an ecosystem and limiting the innovation within an ecosystem because of overreaching requirements.
While I agree there is no one answer, I dispute that the buckets, as outlined in the platform spec, cover even those broad terms in their entirety. As you rightly noted, there is no one answer. Thus, this was why I was asking for definition of products and how those products come to market. What I infer in reading the platform spec is that there are assumptions not stated that constitute a product in such a market segment. For example, what is a "server"? And how would those "servers" be deployed? And designed?
It's impractical to define specific products that a platform spec is targeting. That would require a very narrowly focused platform spec. Not something ARM has tried to do, for good reason, in its platform standardization efforts. Even a "narrow" platform spec for HPC or Automotive will still encompass a wide range of products within its broad product area. OpenSBI is inherently different than the SBI spec in that OpenSBI implements SBI spec. The spec is the interface that the S-mode assumes in OS-A. While you may desire the usage of OpenSBI, that doesn't mean it should be mandated. That's an implementers choice, and I suspect many people will decide to go that way. Also, there is not a standard M-mode software that is all encompassing when thinking about the bootflow. I assert it's up to the product designers, OEMs, and manufacturers to decide what is best for their product.
No platforms are mandating usage of OpenSBI. That is just a very portable implementation of the SBI spec.
Agreed that not all M-mode software is or can be standard(meaning portable / not implementation-specific). Especially the earlier stages in a boot or secure boot flow. There have been presentations at RISC-V events and summits about the RV boot flow being developed. And there are people in RISC-V that are striving to fill in more of the parts with "RV standard" puzzle pieces over the next year+.
Greg
|
|
|
On Wed, Oct 13, 2021 at 7:47 AM Aaron Durbin < adurbin@...> wrote: Could you please describe where end-products would need the RISC-V platform compatibility branding?
That is a higher-level RVI question - on which RVI has decided that developing ISA profile specs and platform specs is a high priority. I'll let others speak about the motivations for these. But from my understanding there is a substantial demand from the ecosystem for branding standards.
Greg
|
|
|
I made a few comments on the policy document, including some proposed
language changes, a month ago and they have yet to receive any response, so
I'm not sure that part of the process is working. Maybe the policy
document needs to be somewhere other than Google Docs; it doesn't seem all
that effective for the type of collaboration necessary.
// darius
toggle quoted message
Show quoted text
On Wed, Oct 13, 2021 at 06:35:04AM -0700, mark wrote: First, thank you for your comments. I agree.
I want to encourage everyone to make comments on the policy (ptr below) or
raise github issues for the spec (
https://github.com/riscv/riscv-platform-specs).
Sometimes we iterate because we don't totally understand the scope of the
issue. I suggest that when you make a comment or raise an issue, please
propose alternate language that addresses your issue. This will help the
folks writing the policies (they are doing a lot of work and can use any
help you can provide) and specs and stands as a good record of what would
remediate the issue and is the best way for us to track issues (email is
good for discussion but these mechanisms force us to resolve them more
reliably). If you can't, then include your proposed change of language in
email.
We are a continuous improvement organization and don't claim to get things
right but we are always open to input and request you help us make things
better.
Mark
On Wed, Oct 13, 2021 at 3:51 AM Darius Rad <darius@...> wrote:
I have been attending the platform spec meetings regularly since inception,
and it seems to me that questions similar to this are frequently brought
up. The typical response, as here, is to provide an answer directly to the
individual that asked the question, sometimes with varying degrees of
detail. Perhaps it would be more productive to take this feedback and
address the specification and policy documents so that these questions
don't have to be repeatedly answered, and, more importantly, to refine the
specification to be more comprehensible to the wider community.
// darius
On Tue, Oct 12, 2021 at 03:37:17PM -0700, Kumar Sankaran wrote:
Agree with what Jonathan has said below.
The platform spec provides a complete set of hardware and software
requirements for a platform. In the case of software, the platform spec
mandates requirements that software running in M-mode or S-mode or
hypervisor mode need to adhere to in order to claim compatibility with that
particular platform.
Also, the platform spec provides a “minimal” set of required functionality
at the hardware and software level for platforms to claim compatibility. It
does not take any particular stance on whether an OEM or a system
integrator were to build the platform or whether a silicon vendor releases
firmware for their reference platform. No such assumptions are made. All we
are mandating in software are the requirements at any privilege level.
The platform spec however adds extensions for specific target markets like
“server”. These extension specific requirements cater to that particular
market segment. The introduction Section 1 of the spec provides some more
detail regarding this.
Hope this answers your questions.
Regards
Kumar
*From:* tech-unixplatformspec@... <
tech-unixplatformspec@...> *On Behalf Of *Jonathan Behrens
*Sent:* Tuesday, October 12, 2021 3:19 PM
*To:* adurbin@...
*Cc:* tech-unixplatformspec@...
*Subject:* Re: [RISC-V] [tech-unixplatformspec] Platform Spec General
Feedback
Other people can probably jump in with the official charter, but I
interpret the platform spec to be defining the interfaces between all
M-mode and S-mode software, plus defining any hardware interfaces they can
rely on. The idea being that if you are implementing an OS or M-mode
firmware or whatever, you know both what is expected of you and what you
can expect from the system.
This also partially answers your other email. The reason certain hardware
devices and features are required is so software can be written assuming
they’ll be present.
Jonathan
On Tue, Oct 12, 2021 at 5:03 PM Aaron Durbin via lists.riscv.org <adurbin=
rivosinc.com@...> wrote:
Hi,
I went through the policy document (
https://docs.google.com/document/d/1U5qLoztZpCRSnw2s8tx4rB0SFPMQ27Svrr9jWRsOziY
)
as well as the platform spec itself (
https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc
).
The policy document certainly seems to be addressing things from a user's
perspective:
"From a user perspective, binary operating systems distributions (such as
the various Linux distributions) should be easily movable between different
hardware."
This makes sense, but it's important to point out that this is targeted for
Supervisor level and up. However, my reading is that many things are
included in the platform spec that are targeting mandates for different
privilege levels which isn't clear to me how this platform is expected to
be adhered to.
My assessment is that this platform spec is written and geared towards the
equivalent of an OEM or system integrator. There, they control the firmware
and what is being implemented. However, that approach assumes a particular
market. i.e. OEMs selling systems to end users. Is that the expectation?
And would then OEMs dictate to the risc-v implementers what they should
create? If this is the intended market I think the platform spec should be
explicit in the assumptions it's making in how systems are packaged and
provided.
Thanks for the help in understanding scoping of intent. It's very murky to
me in how this spec is intended to play out.
-Aaron
|
|
|
On Thu, Oct 14, 2021 at 1:55 AM Greg Favor < gfavor@...> wrote: On Wed, Oct 13, 2021 at 7:32 AM Aaron Durbin < adurbin@...> wrote: Again, I understand that intent. But, what I'm missing is where that diligence was done to declare what is basic. And what is the recourse when someone disagrees with what is deemed basic or minimal for a particular market segment as declared by the platform spec? It be easier to decide if a potential product fits within that predetermined bucket if it was defined. Basically, how inclusive is the platform spec attempting to be on behalf of risc-v implementers?
A minimal platform spec is of corresponding limited value from a standardization and hardware/software interoperability perspective. The M platform does, though tend towards minimal requirements simply because of the enormous range of what "embedded" designs want and don't want to do. The OS-A Base platform tries to strike a balance between what a wide range of implementations/products/markets/etc. want to have and not have. By its nature, it caters to a wide range of products. Even ARM, with SBSA (and its later BSA'sgdidn't try to define what each platform spec was targeting - other than a sentence or two high-level broad description.
Could you please provide the data/opinions which fed into the current decisions in the specification to cover a wide range of implementations/products/markets? I think it's safe to say there are definitely implicit assumptions in the specification. I'm trying to tease those out so they are explicit.
Please correct me, but it's my understanding that the Linux distros are primarily concerned with S-mode and U-mode; that's always been my experience. They do not represent designers or people working in m-mode. This is the layer separation I was alluding to where I think the platform spec is overreaching. I'm glad they are involved and providing feedback, but they are not fully representative of all components that go into designing a product.
Somewhat like profile specs are not just about U-mode or S-mode, platform specs encompass a complete system (not just what an OS or hypervisor sees) - both hardware-wise and software-wise. ARM SBSA/BSA's provide a good example, generally speaking, of what the ecosystem has demanded of ARM as far as platform standardization and not just OS environment standardization (which includes EL3 and Secure world stuff - roughly analogous to M-mode).
Would you agree that RISC-V is not yet there w.r.t. featureset in order to more definitively specify to the level of ARM's SBSA/BSA for RISC-V? I would argue that most of the solutions that are analogous to ARM's SBSA/BSA in the RISC-V ecosystem are not fully vetted in the market place -- nor yet existent. So why push those parts into the platform spec now without having the full suite of solutions? That doesn't answer my question about the view of the platform spec that constitutes what a product is in each of the buckets as defined in the platform spec. Yes, I agree, there are requirements on both hw and sw, but there are degrees of requirements that enter in the realm of product definition which I don't think it should be doing. In other words, there's a balance to strike in building an ecosystem and limiting the innovation within an ecosystem because of overreaching requirements.
While I agree there is no one answer, I dispute that the buckets, as outlined in the platform spec, cover even those broad terms in their entirety. As you rightly noted, there is no one answer. Thus, this was why I was asking for definition of products and how those products come to market. What I infer in reading the platform spec is that there are assumptions not stated that constitute a product in such a market segment. For example, what is a "server"? And how would those "servers" be deployed? And designed?
It's impractical to define specific products that a platform spec is targeting. That would require a very narrowly focused platform spec. Not something ARM has tried to do, for good reason, in its platform standardization efforts. Even a "narrow" platform spec for HPC or Automotive will still encompass a wide range of products within its broad product area.
Again, I am asking what implicit assumptions and framework is being used to decide what is or isn't required for the various segments in the platform spec.
OpenSBI is inherently different than the SBI spec in that OpenSBI implements SBI spec. The spec is the interface that the S-mode assumes in OS-A. While you may desire the usage of OpenSBI, that doesn't mean it should be mandated. That's an implementers choice, and I suspect many people will decide to go that way. Also, there is not a standard M-mode software that is all encompassing when thinking about the bootflow. I assert it's up to the product designers, OEMs, and manufacturers to decide what is best for their product.
No platforms are mandating usage of OpenSBI. That is just a very portable implementation of the SBI spec.
Agreed that not all M-mode software is or can be standard(meaning portable / not implementation-specific). Especially the earlier stages in a boot or secure boot flow. There have been presentations at RISC-V events and summits about the RV boot flow being developed. And there are people in RISC-V that are striving to fill in more of the parts with "RV standard" puzzle pieces over the next year+.
Glad we're on the same page in that we agree the software that runs in M-mode is very wide-ranging and can't necessarily be portable across every design. Greg, you wrote the following up thread:
"Standard M-mode software (just like an OS) needs to know what hardware functionality it can depend on being present. Even implementation-specific M-mode software will still want to have certain standardized components that it can depend on being there that it can make use of."
Not just standard m-mode software but any software needs to know hardware functionality it can depend on being present. However, we already acknowledge there is already implementation specific code in OpenSBI to make those platforms work. Even using ARM Trusted Firmware as an example, all those implementations have platform specific code to make those platforms work. There's no way around picking the right options to build a piece of software to target a particular platform. So what did such a requirement obtain? Take OpenSBI as an example, one could easily push patches to the project for hw support, and that has nothing to do with the platform spec.
-Aaron
|
|
|
On Thu, Oct 14, 2021 at 2:01 AM Greg Favor < gfavor@...> wrote: On Wed, Oct 13, 2021 at 7:47 AM Aaron Durbin < adurbin@...> wrote: Could you please describe where end-products would need the RISC-V platform compatibility branding?
That is a higher-level RVI question - on which RVI has decided that developing ISA profile specs and platform specs is a high priority. I'll let others speak about the motivations for these. But from my understanding there is a substantial demand from the ecosystem for branding standards.
Do you have a pointer to which parts of the ecosystem are represented and what their requests were? I would expect that we should have that data.
-Aaron
|
|
|
mark
can you explain your question. I am not sure what you are asking. ty
On Thu, Oct 14, 2021 at 6:31 AM Aaron Durbin < adurbin@...> wrote:
On Thu, Oct 14, 2021 at 2:01 AM Greg Favor < gfavor@...> wrote: On Wed, Oct 13, 2021 at 7:47 AM Aaron Durbin < adurbin@...> wrote: Could you please describe where end-products would need the RISC-V platform compatibility branding?
That is a higher-level RVI question - on which RVI has decided that developing ISA profile specs and platform specs is a high priority. I'll let others speak about the motivations for these. But from my understanding there is a substantial demand from the ecosystem for branding standards.
Do you have a pointer to which parts of the ecosystem are represented and what their requests were? I would expect that we should have that data.
-Aaron
|
|
|
can you explain your question. I am not sure what you are asking. ty
Greg indicated "substantial demand from the ecosystem for branding standards".
The term ecosystem is broad, and is inherently made up of many entities with different business interests. I was inquiring about the entities of said ecosystem and what exactly they requested. I was expecting that market analysis would be documented and attributed to the representatives of the ecosystem so that people could review.
I hope that is clearer.
-Aaron
On Thu, Oct 14, 2021 at 6:31 AM Aaron Durbin < adurbin@...> wrote:
On Thu, Oct 14, 2021 at 2:01 AM Greg Favor < gfavor@...> wrote: On Wed, Oct 13, 2021 at 7:47 AM Aaron Durbin < adurbin@...> wrote: Could you please describe where end-products would need the RISC-V platform compatibility branding?
That is a higher-level RVI question - on which RVI has decided that developing ISA profile specs and platform specs is a high priority. I'll let others speak about the motivations for these. But from my understanding there is a substantial demand from the ecosystem for branding standards.
Do you have a pointer to which parts of the ecosystem are represented and what their requests were? I would expect that we should have that data.
-Aaron
|
|
|
Kumar Sankaran
Hi Aaron, Can I request you to list all the open non-technical issues that you have raised so far into a slide so we can review and hash some of these out during our next Platform HSC meeting on Monday? We can discuss and close some or most these issues during the meeting. Regards Kumar
From: Aaron Durbin <adurbin@...>
Sent: Thursday, October 14, 2021 10:12 AM
To: Mark Himelstein <markhimelstein@...>
Cc: Greg Favor <gfavor@...>; Kumar Sankaran <ksankaran@...>; Jonathan Behrens <behrensj@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] Platform Spec General Feedback can you explain your question. I am not sure what you are asking. ty
Greg indicated "substantial demand from the ecosystem for branding standards". The term ecosystem is broad, and is inherently made up of many entities with different business interests. I was inquiring about the entities of said ecosystem and what exactly they requested. I was expecting that market analysis would be documented and attributed to the representatives of the ecosystem so that people could review. On Thu, Oct 14, 2021 at 6:31 AM Aaron Durbin <adurbin@...> wrote: On Thu, Oct 14, 2021 at 2:01 AM Greg Favor <gfavor@...> wrote: On Wed, Oct 13, 2021 at 7:47 AM Aaron Durbin <adurbin@...> wrote: Could you please describe where end-products would need the RISC-V platform compatibility branding?
That is a higher-level RVI question - on which RVI has decided that developing ISA profile specs and platform specs is a high priority. I'll let others speak about the motivations for these. But from my understanding there is a substantial demand from the ecosystem for branding standards.
Do you have a pointer to which parts of the ecosystem are represented and what their requests were? I would expect that we should have that data.
|
|
|
Hi Kumar,
I can put some slides together.
-Aaron
On Fri, Oct 15, 2021 at 12:53 AM Kumar Sankaran < ksankaran@...> wrote: Hi Aaron, Can I request you to list all the open non-technical issues that you have raised so far into a slide so we can review and hash some of these out during our next Platform HSC meeting on Monday? We can discuss and close some or most these issues during the meeting. Regards Kumar can you explain your question. I am not sure what you are asking. ty
Greg indicated "substantial demand from the ecosystem for branding standards". The term ecosystem is broad, and is inherently made up of many entities with different business interests. I was inquiring about the entities of said ecosystem and what exactly they requested. I was expecting that market analysis would be documented and attributed to the representatives of the ecosystem so that people could review. On Thu, Oct 14, 2021 at 6:31 AM Aaron Durbin <adurbin@...> wrote: On Thu, Oct 14, 2021 at 2:01 AM Greg Favor <gfavor@...> wrote: On Wed, Oct 13, 2021 at 7:47 AM Aaron Durbin <adurbin@...> wrote: Could you please describe where end-products would need the RISC-V platform compatibility branding?
That is a higher-level RVI question - on which RVI has decided that developing ISA profile specs and platform specs is a high priority. I'll let others speak about the motivations for these. But from my understanding there is a substantial demand from the ecosystem for branding standards.
Do you have a pointer to which parts of the ecosystem are represented and what their requests were? I would expect that we should have that data.
|
|
|
