|
Hi,
After reading through the platform spec I have some feedback on the technical side of things (different from the scoping of intention in my general feedback email).
1. Zam required, but as far as I can see there is no plan for ratification in the current items on the docket for ratification. 2. Unified Discovery is still up in the air, and it's not clear exactly the scope of the problem that it is trying to solve. There's both debug and runtime use cases, but there are issues about dynamic encoding based on fusing, runtime options, even when the mconfigptr is valid, etc. In other words, not everything is fully fleshed out to mandate such a thing, imo. 3. On the server extension, it seems to be implied that UEFI firmware is mandated despite the OS only needing runtime services. What's the reason for forcing a system integrator to use UEFI? And why does it matter what firmware is used to the OS? 4. M-mode runtime must 'Emulate missing CSRs.' Which CSRs are in scope here?
There are HW mandates that I don't think are appropriate:
1. ACLINT - why is this required? This is forcing an implementation to use that when it's not necessarily needed. 2. APLIC - Same question as ACLINT? Relatedly, why are wired IRQs called out as being necessary and supported by way of an APLIC? Why can't wired IRQs be supported in another way? 3. PMPs - I believe this is an M-mode intention to protect m-mode assets. Why is an implementation being mandated instead of requesting M-mode asset protection from the harts? Moreover, there doesn't appear to be a requirement that protects M-mode assets from I/O agents. PMP is well defined, but it isn't necessarily conducive for all product implementations depending on what one's own product requirements are (power, perf, etc).
I look forward to discussing these things in the future.
-Aaron
|
|
|
On 10/12/21 23:23, Aaron Durbin wrote: Hi,
After reading through the platform spec I have some feedback on the technical side of things (different from the scoping of intention in my general feedback email).
1. Zam required, but as far as I can see there is no plan for ratification in the current items on the docket for ratification.
2. Unified Discovery is still up in the air, and it's not clear exactly the scope of the problem that it is trying to solve. There's both debug and runtime use cases, but there are issues about dynamic encoding based on fusing, runtime options, even when the mconfigptr is valid, etc. In other words, not everything is fully fleshed out to mandate such a thing, imo.
3. On the server extension, it seems to be implied that UEFI firmware is mandated despite the OS only needing runtime services. What's the reason for forcing a system integrator to use UEFI? And why does it matter what firmware is used to the OS? It is not only for the server extension but for all profile OS-A systems that the platform specification requires the implementation of as subset of the UEFI API. The specification does not require any specific firmware. Open source implementations exist with EDK II and U-Boot. Conformance with the UEFI platform initialization specification is not required. The UEFI API provides standardized means * to boot an operating system * to update the firmware * to reset and power-off For the operating system the standardized API allows: * to create a single installation medium to boot on all supported RISC-V systems * receive platform information in a system independent way (via devicetree or ACPI tables) * to implement operating system updates in a system independent manner For the system owner the standardized API allows: * to install alternative operating systems without hassle * easily setup dual boot systems Best regards Heinrich 4. M-mode runtime must 'Emulate missing CSRs.' Which CSRs are in scope here?
There are HW mandates that I don't think are appropriate:
1. ACLINT - why is this required? This is forcing an implementation to use that when it's not necessarily needed.
2. APLIC - Same question as ACLINT? Relatedly, why are wired IRQs called out as being necessary and supported by way of an APLIC? Why can't wired IRQs be supported in another way?
3. PMPs - I believe this is an M-mode intention to protect m-mode assets. Why is an implementation being mandated instead of requesting M-mode asset protection from the harts? Moreover, there doesn't appear to be a requirement that protects M-mode assets from I/O agents. PMP is well defined, but it isn't necessarily conducive for all product implementations depending on what one's own product requirements are (power, perf, etc).
I look forward to discussing these things in the future.
-Aaron
|
|
|
On Tue, Oct 12, 2021 at 2:23 PM Aaron Durbin < adurbin@...> wrote: 1. Zam required, but as far as I can see there is no plan for ratification in the current items on the docket for ratification.
Both Zam and Ztso are not yet ratified standards - which is going to start to be rectified soon. 1. ACLINT - why is this required? This is forcing an implementation to use that when it's not necessarily needed.
Keep in mind that it is not as simple as saying that "ACLINT is required". The OS-A Base spec provides four options for what a system implements as far as interrupt control.
In RISC-V there have been two de facto standards (PLIC and CLINT) that were never properly established as official RV standards but are used by many people - which is in the process of being addressed. ACLINT is part of the effort to standardize the existing CLINT, provide more flexibility to CLINT implementations, and to add on the SSWI part that mirrors the existing MSWI part (for systems that don't want or need to implement AIA). 2. APLIC - Same question as ACLINT? Relatedly, why are wired IRQs called out as being necessary and supported by way of an APLIC? Why can't wired IRQs be supported in another way?
The Base platform supports use of PLIC, ACLINT, and AIA (and its IMSIC and APLIC parts). It is not requiring that all OS-A Base compliant systems implement APLIC (or any part of AIA).
For supporting wired interrupts one has two choices - PLIC and APLIC. (And within RISC-V there will also be CLIC for more embedded-oriented designs.)
3. PMPs - I believe this is an M-mode intention to protect m-mode assets. Why is an implementation being mandated instead of requesting M-mode asset protection from the harts? Moreover, there doesn't appear to be a requirement that protects M-mode assets from I/O agents.
Note that the current RV architecture (other than things like AIA, Debug, and E-Trace) is "CPU" architecture. Things like IOPMP and IOMMU will address the needs around I/O agents in a system (including equivalents to CPU PMAs and PMPs). Greg
|
|
|
On 10/12/21 23:23, Aaron Durbin wrote:
> Hi,
>
> After reading through the platform spec I have some feedback on the
> technical side of things (different from the scoping of intention in my
> general feedback email).
>
> 1. Zam required, but as far as I can see there is no plan for
> ratification in the current items on the docket for ratification.
> 2. Unified Discovery is still up in the air, and it's not clear
> exactly the scope of the problem that it is trying to solve. There's
> both debug and runtime use cases, but there are issues about dynamic
> encoding based on fusing, runtime options, even when the mconfigptr is
> valid, etc. In other words, not everything is fully fleshed out to
> mandate such a thing, imo.
> 3. On the server extension, it seems to be implied that UEFI firmware is
> mandated despite the OS only needing runtime services. What's the reason
> for forcing a system integrator to use UEFI? And why does it matter what
> firmware is used to the OS?
It is not only for the server extension but for all profile OS-A systems
that the platform specification requires the implementation of as subset
of the UEFI API.
The specification does not require any specific firmware. Open source
implementations exist with EDK II and U-Boot.
OS-A doesn't indicate much w.r.t. UEFI aside from use UEFI interface from the OS. Server extension mandates implementing large pieces of UEFI spec:
"The boot and system firmware for the server platforms must support UEFI as defined in the section 2.6 of the UEFI Specification ..."
That indicates implementing UEFI and subsequently dictates other protocols. Therefore, implementing UEFI is inherently mandated.
Conformance with the UEFI platform initialization specification is not
required.
The UEFI API provides standardized means
* to boot an operating system
* to update the firmware
* to reset and power-off
Through the use of runtime services and boot services interfaces, correct?
For the operating system the standardized API allows:
* to create a single installation medium to boot on all supported RISC-V
systems
* receive platform information in a system independent way (via
devicetree or ACPI tables)
* to implement operating system updates in a system independent manner
I'm pretty sure those items don't require UEFI.
For the system owner the standardized API allows:
* to install alternative operating systems without hassle
* easily setup dual boot systems
So the platform spec is not just for OS interfacing with. It's also mandating end-user requirements. Who is the end-user? In my experience, I think what you wrote is valid depending on the user. In other situations it is not valid because those requirements do not exist, and they insist on not having UEFI implementations in the firmware.
I think we need to clearly lay out the underlying intention and not dictate how such a thing is followed. Or we acknowledge and clearly define who the end-user is and the assumption in how they would use the product itself.
-Aaron
|
|
|
On Tue, Oct 12, 2021 at 9:51 PM Greg Favor < gfavor@...> wrote: On Tue, Oct 12, 2021 at 2:23 PM Aaron Durbin < adurbin@...> wrote: 1. Zam required, but as far as I can see there is no plan for ratification in the current items on the docket for ratification.
Both Zam and Ztso are not yet ratified standards - which is going to start to be rectified soon.
What's the plan for soon? And what is the definition of soon? It's not in the list of things to be standardized this Fall. It would be good to have visibility on these fronts.
1. ACLINT - why is this required? This is forcing an implementation to use that when it's not necessarily needed.
Keep in mind that it is not as simple as saying that "ACLINT is required". The OS-A Base spec provides four options for what a system implements as far as interrupt control.
The 2.1.4.1. Timer support section states "One or more ACLINT MTIMER devices are required for the OS-A platform"
Is the MTIMER device inclusive of the MTIME register and the set of MTIMECMP register sets? And what is the thinking here along with Sstc extension?
It might even be worth separating the MTIMER device from the ACLINT spec itself since the requirement above is standalone.
In RISC-V there have been two de facto standards (PLIC and CLINT) that were never properly established as official RV standards but are used by many people - which is in the process of being addressed. ACLINT is part of the effort to standardize the existing CLINT, provide more flexibility to CLINT implementations, and to add on the SSWI part that mirrors the existing MSWI part (for systems that don't want or need to implement AIA).
Thank you for the history. 2. APLIC - Same question as ACLINT? Relatedly, why are wired IRQs called out as being necessary and supported by way of an APLIC? Why can't wired IRQs be supported in another way?
The Base platform supports use of PLIC, ACLINT, and AIA (and its IMSIC and APLIC parts). It is not requiring that all OS-A Base compliant systems implement APLIC (or any part of AIA).
But there is no option to not implement an APLIC or PLIC, correct? Why not? IMSIC on its own is certainly valid.
For supporting wired interrupts one has two choices - PLIC and APLIC. (And within RISC-V there will also be CLIC for more embedded-oriented designs.)
Why just those two? And are these wired interrupts internal to a part or external? Why couldn't one implement a different way to generate IRQs from an external wire? That is definitely dictating product implementation.
And where does this 'wired IRQ' requirement come from exactly? There's seems to be some implied assumptions, but they are not clear what that section is trying to address. 3. PMPs - I believe this is an M-mode intention to protect m-mode assets. Why is an implementation being mandated instead of requesting M-mode asset protection from the harts? Moreover, there doesn't appear to be a requirement that protects M-mode assets from I/O agents.
Note that the current RV architecture (other than things like AIA, Debug, and E-Trace) is "CPU" architecture. Things like IOPMP and IOMMU will address the needs around I/O agents in a system (including equivalents to CPU PMAs and PMPs).
So the spec doesn't address m-mode asset protection fully, but it decided to focus on "cpu" and force an implementation? I understand the distinction between hart and !hart, but I don't see the point of requiring PMP specifically. What should be in the spec is the intention: provide a mechanism to protect m-mode assets from hart access as well as I/O agents.
-Aaron
|
|
|
Jonathan Behrens <behrensj@...>
3.
PMPs - I believe this is an M-mode intention to protect m-mode assets.
Why is an implementation being mandated instead of requesting M-mode
asset protection from the harts? Moreover, there doesn't appear to be a
requirement that protects M-mode assets from I/O agents.
Note
that the current RV architecture (other than things like AIA, Debug,
and E-Trace) is "CPU" architecture. Things like IOPMP and IOMMU will
address the needs around I/O agents in a system (including equivalents
to CPU PMAs and PMPs).
So
the spec doesn't address m-mode asset protection fully, but it decided
to focus on "cpu" and force an implementation? I understand the
distinction between hart and !hart, but I don't see the point of
requiring PMP specifically. What should be in the spec is the intention:
provide a mechanism to protect m-mode assets from hart access as well
as I/O agents.
The spec requires PMP so that standard M-mode software like OpenSBI can assume that PMP is implemented. If the requirement was "PMP or any other asset protection implementation" then OpenSBI would need to have special handling for every different possible implementation. I'd also point out that PMP isn't just for defending against malicious code, it also protects against buggy code accidentally corrupting M-mode memory.
Jonathan
On Tue, Oct 12, 2021 at 9:51 PM Greg Favor < gfavor@...> wrote: On Tue, Oct 12, 2021 at 2:23 PM Aaron Durbin < adurbin@...> wrote: 1. Zam required, but as far as I can see there is no plan for ratification in the current items on the docket for ratification.
Both Zam and Ztso are not yet ratified standards - which is going to start to be rectified soon.
What's the plan for soon? And what is the definition of soon? It's not in the list of things to be standardized this Fall. It would be good to have visibility on these fronts.
1. ACLINT - why is this required? This is forcing an implementation to use that when it's not necessarily needed.
Keep in mind that it is not as simple as saying that "ACLINT is required". The OS-A Base spec provides four options for what a system implements as far as interrupt control.
The 2.1.4.1. Timer support section states "One or more ACLINT MTIMER devices are required for the OS-A platform"
Is the MTIMER device inclusive of the MTIME register and the set of MTIMECMP register sets? And what is the thinking here along with Sstc extension?
It might even be worth separating the MTIMER device from the ACLINT spec itself since the requirement above is standalone.
In RISC-V there have been two de facto standards (PLIC and CLINT) that were never properly established as official RV standards but are used by many people - which is in the process of being addressed. ACLINT is part of the effort to standardize the existing CLINT, provide more flexibility to CLINT implementations, and to add on the SSWI part that mirrors the existing MSWI part (for systems that don't want or need to implement AIA).
Thank you for the history. 2. APLIC - Same question as ACLINT? Relatedly, why are wired IRQs called out as being necessary and supported by way of an APLIC? Why can't wired IRQs be supported in another way?
The Base platform supports use of PLIC, ACLINT, and AIA (and its IMSIC and APLIC parts). It is not requiring that all OS-A Base compliant systems implement APLIC (or any part of AIA).
But there is no option to not implement an APLIC or PLIC, correct? Why not? IMSIC on its own is certainly valid.
For supporting wired interrupts one has two choices - PLIC and APLIC. (And within RISC-V there will also be CLIC for more embedded-oriented designs.)
Why just those two? And are these wired interrupts internal to a part or external? Why couldn't one implement a different way to generate IRQs from an external wire? That is definitely dictating product implementation.
And where does this 'wired IRQ' requirement come from exactly? There's seems to be some implied assumptions, but they are not clear what that section is trying to address. 3. PMPs - I believe this is an M-mode intention to protect m-mode assets. Why is an implementation being mandated instead of requesting M-mode asset protection from the harts? Moreover, there doesn't appear to be a requirement that protects M-mode assets from I/O agents.
Note that the current RV architecture (other than things like AIA, Debug, and E-Trace) is "CPU" architecture. Things like IOPMP and IOMMU will address the needs around I/O agents in a system (including equivalents to CPU PMAs and PMPs).
So the spec doesn't address m-mode asset protection fully, but it decided to focus on "cpu" and force an implementation? I understand the distinction between hart and !hart, but I don't see the point of requiring PMP specifically. What should be in the spec is the intention: provide a mechanism to protect m-mode assets from hart access as well as I/O agents.
-Aaron
|
|
|
Hi Aaron, On Wed, Oct 13, 2021 at 09:00:49AM -0600, Aaron Durbin wrote: On Tue, Oct 12, 2021 at 9:28 PM Heinrich Schuchardt <
heinrich.schuchardt@...> wrote:
On 10/12/21 23:23, Aaron Durbin wrote:
Hi,
After reading through the platform spec I have some feedback on the
technical side of things (different from the scoping of intention in my
general feedback email).
1. Zam required, but as far as I can see there is no plan for
ratification in the current items on the docket for ratification.
2. Unified Discovery is still up in the air, and it's not clear
exactly the scope of the problem that it is trying to solve. There's
both debug and runtime use cases, but there are issues about dynamic
encoding based on fusing, runtime options, even when the mconfigptr is
valid, etc. In other words, not everything is fully fleshed out to
mandate such a thing, imo.
3. On the server extension, it seems to be implied that UEFI firmware is
mandated despite the OS only needing runtime services. What's the reason
for forcing a system integrator to use UEFI? And why does it matter what
firmware is used to the OS? It is not only for the server extension but for all profile OS-A systems
that the platform specification requires the implementation of as subset
of the UEFI API.
The specification does not require any specific firmware. Open source
implementations exist with EDK II and U-Boot.
OS-A doesn't indicate much w.r.t. UEFI aside from use UEFI interface from
the OS. Server extension mandates implementing large pieces of UEFI spec: OS-A refers to EBBR which mandates reduced set of UEFI interfaces.
"The boot and system firmware for the server platforms must support UEFI as
defined in the section 2.6 of the UEFI Specification ..."
That indicates implementing UEFI and subsequently dictates other protocols.
Therefore, implementing UEFI is inherently mandated.
Yes, UEFI is mandatory for server OS distros. What "other protocols" which you think not necessary to support server OSs? Regards Sunil
Conformance with the UEFI platform initialization specification is not
required.
The UEFI API provides standardized means
* to boot an operating system
* to update the firmware
* to reset and power-off
Through the use of runtime services and boot services interfaces, correct?
For the operating system the standardized API allows:
* to create a single installation medium to boot on all supported RISC-V
systems
* receive platform information in a system independent way (via
devicetree or ACPI tables)
* to implement operating system updates in a system independent manner
I'm pretty sure those items don't require UEFI.
For the system owner the standardized API allows:
* to install alternative operating systems without hassle
* easily setup dual boot systems
So the platform spec is not just for OS interfacing with. It's also
mandating end-user requirements. Who is the end-user? In my experience, I
think what you wrote is valid depending on the user. In other situations it
is not valid because those requirements do not exist, and they insist on
not having UEFI implementations in the firmware.
I think we need to clearly lay out the underlying intention and not dictate
how such a thing is followed. Or we acknowledge and clearly define who the
end-user is and the assumption in how they would use the product itself.
-Aaron
|
|
|
On Wed, Oct 13, 2021 at 9:50 AM Jonathan Behrens < behrensj@...> wrote: 3.
PMPs - I believe this is an M-mode intention to protect m-mode assets.
Why is an implementation being mandated instead of requesting M-mode
asset protection from the harts? Moreover, there doesn't appear to be a
requirement that protects M-mode assets from I/O agents.
Note
that the current RV architecture (other than things like AIA, Debug,
and E-Trace) is "CPU" architecture. Things like IOPMP and IOMMU will
address the needs around I/O agents in a system (including equivalents
to CPU PMAs and PMPs).
So
the spec doesn't address m-mode asset protection fully, but it decided
to focus on "cpu" and force an implementation? I understand the
distinction between hart and !hart, but I don't see the point of
requiring PMP specifically. What should be in the spec is the intention:
provide a mechanism to protect m-mode assets from hart access as well
as I/O agents.
The spec requires PMP so that standard M-mode software like OpenSBI can assume that PMP is implemented. If the requirement was "PMP or any other asset protection implementation" then OpenSBI would need to have special handling for every different possible implementation. I'd also point out that PMP isn't just for defending against malicious code, it also protects against buggy code accidentally corrupting M-mode memory.
OpenSBI implementation already has platform specific code in it. PMP, as specified, is not conducive to all designs. It has power and performance implications that can be onerous depending on what one is optimizing for. Is the platform spec trying to protect the OpenSBI software project?
On Tue, Oct 12, 2021 at 9:51 PM Greg Favor < gfavor@...> wrote: On Tue, Oct 12, 2021 at 2:23 PM Aaron Durbin < adurbin@...> wrote: 1. Zam required, but as far as I can see there is no plan for ratification in the current items on the docket for ratification.
Both Zam and Ztso are not yet ratified standards - which is going to start to be rectified soon.
What's the plan for soon? And what is the definition of soon? It's not in the list of things to be standardized this Fall. It would be good to have visibility on these fronts.
1. ACLINT - why is this required? This is forcing an implementation to use that when it's not necessarily needed.
Keep in mind that it is not as simple as saying that "ACLINT is required". The OS-A Base spec provides four options for what a system implements as far as interrupt control.
The 2.1.4.1. Timer support section states "One or more ACLINT MTIMER devices are required for the OS-A platform"
Is the MTIMER device inclusive of the MTIME register and the set of MTIMECMP register sets? And what is the thinking here along with Sstc extension?
It might even be worth separating the MTIMER device from the ACLINT spec itself since the requirement above is standalone.
In RISC-V there have been two de facto standards (PLIC and CLINT) that were never properly established as official RV standards but are used by many people - which is in the process of being addressed. ACLINT is part of the effort to standardize the existing CLINT, provide more flexibility to CLINT implementations, and to add on the SSWI part that mirrors the existing MSWI part (for systems that don't want or need to implement AIA).
Thank you for the history. 2. APLIC - Same question as ACLINT? Relatedly, why are wired IRQs called out as being necessary and supported by way of an APLIC? Why can't wired IRQs be supported in another way?
The Base platform supports use of PLIC, ACLINT, and AIA (and its IMSIC and APLIC parts). It is not requiring that all OS-A Base compliant systems implement APLIC (or any part of AIA).
But there is no option to not implement an APLIC or PLIC, correct? Why not? IMSIC on its own is certainly valid.
For supporting wired interrupts one has two choices - PLIC and APLIC. (And within RISC-V there will also be CLIC for more embedded-oriented designs.)
Why just those two? And are these wired interrupts internal to a part or external? Why couldn't one implement a different way to generate IRQs from an external wire? That is definitely dictating product implementation.
And where does this 'wired IRQ' requirement come from exactly? There's seems to be some implied assumptions, but they are not clear what that section is trying to address. 3. PMPs - I believe this is an M-mode intention to protect m-mode assets. Why is an implementation being mandated instead of requesting M-mode asset protection from the harts? Moreover, there doesn't appear to be a requirement that protects M-mode assets from I/O agents.
Note that the current RV architecture (other than things like AIA, Debug, and E-Trace) is "CPU" architecture. Things like IOPMP and IOMMU will address the needs around I/O agents in a system (including equivalents to CPU PMAs and PMPs).
So the spec doesn't address m-mode asset protection fully, but it decided to focus on "cpu" and force an implementation? I understand the distinction between hart and !hart, but I don't see the point of requiring PMP specifically. What should be in the spec is the intention: provide a mechanism to protect m-mode assets from hart access as well as I/O agents.
-Aaron
|
|
|
On Wed, Oct 13, 2021 at 9:54 AM Sunil V L < sunilvl@...> wrote: Hi Aaron,
On Wed, Oct 13, 2021 at 09:00:49AM -0600, Aaron Durbin wrote:
> On Tue, Oct 12, 2021 at 9:28 PM Heinrich Schuchardt <
> heinrich.schuchardt@...> wrote:
>
> >
> >
> > On 10/12/21 23:23, Aaron Durbin wrote:
> > > Hi,
> > >
> > > After reading through the platform spec I have some feedback on the
> > > technical side of things (different from the scoping of intention in my
> > > general feedback email).
> > >
> > > 1. Zam required, but as far as I can see there is no plan for
> > > ratification in the current items on the docket for ratification.
> > > 2. Unified Discovery is still up in the air, and it's not clear
> > > exactly the scope of the problem that it is trying to solve. There's
> > > both debug and runtime use cases, but there are issues about dynamic
> > > encoding based on fusing, runtime options, even when the mconfigptr is
> > > valid, etc. In other words, not everything is fully fleshed out to
> > > mandate such a thing, imo.
> > > 3. On the server extension, it seems to be implied that UEFI firmware is
> > > mandated despite the OS only needing runtime services. What's the reason
> > > for forcing a system integrator to use UEFI? And why does it matter what
> > > firmware is used to the OS?
> >
> > It is not only for the server extension but for all profile OS-A systems
> > that the platform specification requires the implementation of as subset
> > of the UEFI API.
> >
> > The specification does not require any specific firmware. Open source
> > implementations exist with EDK II and U-Boot.
> >
>
> OS-A doesn't indicate much w.r.t. UEFI aside from use UEFI interface from
> the OS. Server extension mandates implementing large pieces of UEFI spec:
OS-A refers to EBBR which mandates reduced set of UEFI interfaces.
>
> "The boot and system firmware for the server platforms must support UEFI as
> defined in the section 2.6 of the UEFI Specification ..."
>
> That indicates implementing UEFI and subsequently dictates other protocols.
> Therefore, implementing UEFI is inherently mandated.
Yes, UEFI is mandatory for server OS distros. What "other protocols"
which you think not necessary to support server OSs?
The EBBR is required currently to be implemented/presented. It transitively requires a different UEFI version than what is in the platform spec (2.8 Errata A in EBBR while 2.9 in platform spec), fwiw. Implementing those interfaces should be the only requirement if EBBR is specified, but we're composing requirements from a multitude of sources, and it's not clear what spec overrides what requirement. i.e. how are the various specifications supposed to be composed?
As you noted, you are focusing on server OS distros. While not called out in the platform spec proper, the assumption for the platform spec is focusing on products that would primarily load OS binary distros?
Is the platform spec also assuming a particular kernel loader? Is the term 'OS' encompassing requirements for loader and kernel?
I guess I'm confused that the platform spec is calling out specific protocols that are not required in EBBR (pcie can make sense if it's required to boot, as EBBR dictates, but that's not necessarily true depending on the topology of the system for booting). e.g. why is EFI_LOAD_FILE2_PROTOCOL included?
EFI_LOAD_FILE_PROTOCOL says "The Load File protocol is used to obtain files, that are primarily boot options, from arbitrary devices." EFI_LOAD_FILE2_PROTOCOL says "The Load File 2 protocol is used to obtain files from arbitrary devices that are not boot options."
The former is not required, but the latter is. How come?
Regards
Sunil
>
>
> >
> > Conformance with the UEFI platform initialization specification is not
> > required.
> >
> > The UEFI API provides standardized means
> >
> > * to boot an operating system
> > * to update the firmware
> > * to reset and power-off
> >
>
> Through the use of runtime services and boot services interfaces, correct?
>
>
> >
> > For the operating system the standardized API allows:
> >
> > * to create a single installation medium to boot on all supported RISC-V
> > systems
> > * receive platform information in a system independent way (via
> > devicetree or ACPI tables)
> > * to implement operating system updates in a system independent manner
> >
>
> I'm pretty sure those items don't require UEFI.
>
>
> >
> > For the system owner the standardized API allows:
> >
> > * to install alternative operating systems without hassle
> > * easily setup dual boot systems
> >
>
> So the platform spec is not just for OS interfacing with. It's also
> mandating end-user requirements. Who is the end-user? In my experience, I
> think what you wrote is valid depending on the user. In other situations it
> is not valid because those requirements do not exist, and they insist on
> not having UEFI implementations in the firmware.
>
> I think we need to clearly lay out the underlying intention and not dictate
> how such a thing is followed. Or we acknowledge and clearly define who the
> end-user is and the assumption in how they would use the product itself.
>
> -Aaron
>
>
>
>
>
|
|
|
On 10/13/21 18:49, Aaron Durbin wrote: On Wed, Oct 13, 2021 at 9:54 AM Sunil V L <sunilvl@... <mailto:sunilvl@...>> wrote:
Hi Aaron,
On Wed, Oct 13, 2021 at 09:00:49AM -0600, Aaron Durbin wrote:
> On Tue, Oct 12, 2021 at 9:28 PM Heinrich Schuchardt <
> heinrich.schuchardt@...
<mailto:heinrich.schuchardt@...>> wrote:
>
> >
> >
> > On 10/12/21 23:23, Aaron Durbin wrote:
> > > Hi,
> > >
> > > After reading through the platform spec I have some feedback
on the
> > > technical side of things (different from the scoping of
intention in my
> > > general feedback email).
> > >
> > > 1. Zam required, but as far as I can see there is no plan for
> > > ratification in the current items on the docket for ratification.
> > > 2. Unified Discovery is still up in the air, and it's not clear
> > > exactly the scope of the problem that it is trying to solve.
There's
> > > both debug and runtime use cases, but there are issues about
dynamic
> > > encoding based on fusing, runtime options, even when the
mconfigptr is
> > > valid, etc. In other words, not everything is fully fleshed
out to
> > > mandate such a thing, imo.
> > > 3. On the server extension, it seems to be implied that UEFI
firmware is
> > > mandated despite the OS only needing runtime services. What's
the reason
> > > for forcing a system integrator to use UEFI? And why does it
matter what
> > > firmware is used to the OS?
> >
> > It is not only for the server extension but for all profile
OS-A systems
> > that the platform specification requires the implementation of
as subset
> > of the UEFI API.
> >
> > The specification does not require any specific firmware. Open
source
> > implementations exist with EDK II and U-Boot.
> >
>
> OS-A doesn't indicate much w.r.t. UEFI aside from use UEFI
interface from
> the OS. Server extension mandates implementing large pieces of
UEFI spec:
OS-A refers to EBBR which mandates reduced set of UEFI interfaces.
>
> "The boot and system firmware for the server platforms must
support UEFI as
> defined in the section 2.6 of the UEFI Specification ..."
>
> That indicates implementing UEFI and subsequently dictates other
protocols.
> Therefore, implementing UEFI is inherently mandated.
Yes, UEFI is mandatory for server OS distros. What "other protocols"
which you think not necessary to support server OSs?
The EBBR is required currently to be implemented/presented. It transitively requires a different UEFI version than what is in the platform spec (2.8 Errata A in EBBR while 2.9 in platform spec), fwiw. With version 2.0.1 the EBBR switches to UEFI spec 2.9. See the changelog in https://github.com/ARM-software/ebbr/blob/main/source/index.rstImplementing those interfaces should be the only requirement if EBBR is specified, but we're composing requirements from a multitude of sources, and it's not clear what spec overrides what requirement. i.e. how are the various specifications supposed to be composed?
As you noted, you are focusing on server OS distros. While not called out in the platform spec proper, the assumption for the platform spec is focusing on products that would primarily load OS binary distros?
Is the platform spec also assuming a particular kernel loader? Is the term 'OS' encompassing requirements for loader and kernel?
I guess I'm confused that the platform spec is calling out specific protocols that are not required in EBBR (pcie can make sense if it's required to boot, as EBBR dictates, but that's not necessarily true depending on the topology of the system for booting). e.g. why is EFI_LOAD_FILE2_PROTOCOL included?
EFI_LOAD_FILE_PROTOCOL says "The Load File protocol is used to obtain files, that are primarily boot options, from arbitrary devices."
EFI_LOAD_FILE2_PROTOCOL says "The Load File 2 protocol is used to obtain files from arbitrary devices that are not boot options."
The former is not required, but the latter is. How come? The boot service LoadImage() is required via the EFI_LOAD_FILE_PROTOCOL and EFI_LOAD_FILE2_PROTOCOL according to the UEFI specification. This is implemented in U-Boot and EDK II. Requiring implementing the EFI_LOAD_FILE2_PROTOCOL in the sense of offering a file inside the firmware does not make any sense without specifying which file shall be presented. The EFI_LOAD_FILE2_PROTOCOL requirement needs some clarification in the specification. Best regards Heinrich Regards
Sunil
>
>
> >
> > Conformance with the UEFI platform initialization specification
is not
> > required.
> >
> > The UEFI API provides standardized means
> >
> > * to boot an operating system
> > * to update the firmware
> > * to reset and power-off
> >
>
> Through the use of runtime services and boot services interfaces,
correct?
>
>
> >
> > For the operating system the standardized API allows:
> >
> > * to create a single installation medium to boot on all
supported RISC-V
> > systems
> > * receive platform information in a system independent way (via
> > devicetree or ACPI tables)
> > * to implement operating system updates in a system independent
manner
> >
>
> I'm pretty sure those items don't require UEFI.
>
>
> >
> > For the system owner the standardized API allows:
> >
> > * to install alternative operating systems without hassle
> > * easily setup dual boot systems
> >
>
> So the platform spec is not just for OS interfacing with. It's also
> mandating end-user requirements. Who is the end-user? In my
experience, I
> think what you wrote is valid depending on the user. In other
situations it
> is not valid because those requirements do not exist, and they
insist on
> not having UEFI implementations in the firmware.
>
> I think we need to clearly lay out the underlying intention and
not dictate
> how such a thing is followed. Or we acknowledge and clearly
define who the
> end-user is and the assumption in how they would use the product
itself.
>
> -Aaron
>
>
>
>
|
|
|
On 10/13/21 18:49, Aaron Durbin wrote:
>
>
> On Wed, Oct 13, 2021 at 9:54 AM Sunil V L <sunilvl@...
> <mailto:sunilvl@...>> wrote:
>
> Hi Aaron,
>
> On Wed, Oct 13, 2021 at 09:00:49AM -0600, Aaron Durbin wrote:
> > On Tue, Oct 12, 2021 at 9:28 PM Heinrich Schuchardt <
> > heinrich.schuchardt@...
> <mailto:heinrich.schuchardt@...>> wrote:
> >
> > >
> > >
> > > On 10/12/21 23:23, Aaron Durbin wrote:
> > > > Hi,
> > > >
> > > > After reading through the platform spec I have some feedback
> on the
> > > > technical side of things (different from the scoping of
> intention in my
> > > > general feedback email).
> > > >
> > > > 1. Zam required, but as far as I can see there is no plan for
> > > > ratification in the current items on the docket for ratification.
> > > > 2. Unified Discovery is still up in the air, and it's not clear
> > > > exactly the scope of the problem that it is trying to solve.
> There's
> > > > both debug and runtime use cases, but there are issues about
> dynamic
> > > > encoding based on fusing, runtime options, even when the
> mconfigptr is
> > > > valid, etc. In other words, not everything is fully fleshed
> out to
> > > > mandate such a thing, imo.
> > > > 3. On the server extension, it seems to be implied that UEFI
> firmware is
> > > > mandated despite the OS only needing runtime services. What's
> the reason
> > > > for forcing a system integrator to use UEFI? And why does it
> matter what
> > > > firmware is used to the OS?
> > >
> > > It is not only for the server extension but for all profile
> OS-A systems
> > > that the platform specification requires the implementation of
> as subset
> > > of the UEFI API.
> > >
> > > The specification does not require any specific firmware. Open
> source
> > > implementations exist with EDK II and U-Boot.
> > >
> >
> > OS-A doesn't indicate much w.r.t. UEFI aside from use UEFI
> interface from
> > the OS. Server extension mandates implementing large pieces of
> UEFI spec:
>
> OS-A refers to EBBR which mandates reduced set of UEFI interfaces.
>
> >
> > "The boot and system firmware for the server platforms must
> support UEFI as
> > defined in the section 2.6 of the UEFI Specification ..."
> >
> > That indicates implementing UEFI and subsequently dictates other
> protocols.
> > Therefore, implementing UEFI is inherently mandated.
>
> Yes, UEFI is mandatory for server OS distros. What "other protocols"
> which you think not necessary to support server OSs?
>
>
> The EBBR is required currently to be implemented/presented. It
> transitively requires a different UEFI version than what is in the
> platform spec (2.8 Errata A in EBBR while 2.9 in platform spec), fwiw.
With version 2.0.1 the EBBR switches to UEFI spec 2.9.
See the changelog in
https://github.com/ARM-software/ebbr/blob/main/source/index.rst
If we're going to call out specific versions we should be able to directly link to the spec that only has that version specified. In this case, we're pointing to 2.0.0, but it also seems it's not a particular revision.
> Implementing those interfaces should be the only requirement if EBBR is
> specified, but we're composing requirements from a multitude of sources,
> and it's not clear what spec overrides what requirement. i.e. how are
> the various specifications supposed to be composed?
>
> As you noted, you are focusing on server OS distros. While not called
> out in the platform spec proper, the assumption for the platform spec is
> focusing on products that would primarily load OS binary distros?
> Is the platform spec also assuming a particular kernel loader? Is the
> term 'OS' encompassing requirements for loader and kernel?
>
> I guess I'm confused that the platform spec is calling out specific
> protocols that are not required in EBBR (pcie can make sense if it's
> required to boot, as EBBR dictates, but that's not necessarily true
> depending on the topology of the system for booting). e.g. why
> is EFI_LOAD_FILE2_PROTOCOL included?
>
> EFI_LOAD_FILE_PROTOCOL says "The Load File protocol is used to obtain
> files, that are primarily boot options, from arbitrary devices."
> EFI_LOAD_FILE2_PROTOCOL says "The Load File 2 protocol is used to obtain
> files from arbitrary devices that are not boot options."
>
> The former is not required, but the latter is. How come?
The boot service LoadImage() is required via the EFI_LOAD_FILE_PROTOCOL
and EFI_LOAD_FILE2_PROTOCOL according to the UEFI specification. This is
implemented in U-Boot and EDK II.
Requiring implementing the EFI_LOAD_FILE2_PROTOCOL in the sense of
offering a file inside the firmware does not make any sense without
specifying which file shall be presented.
The EFI_LOAD_FILE2_PROTOCOL requirement needs some clarification in the
specification.
Best regards
Heinrich
>
>
> Regards
> Sunil
>
> >
> >
> > >
> > > Conformance with the UEFI platform initialization specification
> is not
> > > required.
> > >
> > > The UEFI API provides standardized means
> > >
> > > * to boot an operating system
> > > * to update the firmware
> > > * to reset and power-off
> > >
> >
> > Through the use of runtime services and boot services interfaces,
> correct?
> >
> >
> > >
> > > For the operating system the standardized API allows:
> > >
> > > * to create a single installation medium to boot on all
> supported RISC-V
> > > systems
> > > * receive platform information in a system independent way (via
> > > devicetree or ACPI tables)
> > > * to implement operating system updates in a system independent
> manner
> > >
> >
> > I'm pretty sure those items don't require UEFI.
>
>
> >
> >
> > >
> > > For the system owner the standardized API allows:
> > >
> > > * to install alternative operating systems without hassle
> > > * easily setup dual boot systems
> > >
> >
> > So the platform spec is not just for OS interfacing with. It's also
> > mandating end-user requirements. Who is the end-user? In my
> experience, I
> > think what you wrote is valid depending on the user. In other
> situations it
> > is not valid because those requirements do not exist, and they
> insist on
> > not having UEFI implementations in the firmware.
> >
> > I think we need to clearly lay out the underlying intention and
> not dictate
> > how such a thing is followed. Or we acknowledge and clearly
> define who the
> > end-user is and the assumption in how they would use the product
> itself.
> >
> > -Aaron
> >
> >
> >
> >
> >
>
|
|
|
On Wed, 2021-10-13 at 11:50 -0600, Aaron Durbin wrote:
On Wed, Oct 13, 2021 at 11:43 AM Heinrich Schuchardt <
heinrich.schuchardt@...> wrote:
On 10/13/21 18:49, Aaron Durbin wrote:
On Wed, Oct 13, 2021 at 9:54 AM Sunil V L <
sunilvl@...
<mailto:sunilvl@...>> wrote:
Hi Aaron,
On Wed, Oct 13, 2021 at 09:00:49AM -0600, Aaron Durbin wrote:
> On Tue, Oct 12, 2021 at 9:28 PM Heinrich Schuchardt <
> heinrich.schuchardt@...
<mailto:heinrich.schuchardt@...>> wrote:
>
> >
> >
> > On 10/12/21 23:23, Aaron Durbin wrote:
> > > Hi,
> > >
> > > After reading through the platform spec I have some
feedback
on the
> > > technical side of things (different from the scoping of
intention in my
> > > general feedback email).
> > >
> > > 1. Zam required, but as far as I can see there is no plan for
> > > ratification in the current items on the docket for ratification.
> > > 2. Unified Discovery is still up in the air, and it's not clear
> > > exactly the scope of the problem that it is trying to solve.
There's
> > > both debug and runtime use cases, but there are issues about
dynamic
> > > encoding based on fusing, runtime options, even when
the
mconfigptr is
> > > valid, etc. In other words, not everything is fully fleshed
out to
> > > mandate such a thing, imo.
> > > 3. On the server extension, it seems to be implied that UEFI
firmware is
> > > mandated despite the OS only needing runtime services. What's
the reason
> > > for forcing a system integrator to use UEFI? And why does it
matter what
> > > firmware is used to the OS?
> >
> > It is not only for the server extension but for all profile
OS-A systems
> > that the platform specification requires the implementation of
as subset
> > of the UEFI API.
> >
> > The specification does not require any specific firmware. Open
source
> > implementations exist with EDK II and U-Boot.
> >
>
> OS-A doesn't indicate much w.r.t. UEFI aside from use UEFI
interface from
> the OS. Server extension mandates implementing large pieces of
UEFI spec:
OS-A refers to EBBR which mandates reduced set of UEFI interfaces.
>
> "The boot and system firmware for the server platforms must
support UEFI as
> defined in the section 2.6 of the UEFI Specification ..."
>
> That indicates implementing UEFI and subsequently dictates
other
protocols.
> Therefore, implementing UEFI is inherently mandated.
Yes, UEFI is mandatory for server OS distros. What "other protocols"
which you think not necessary to support server OSs?
The EBBR is required currently to be implemented/presented. It
transitively requires a different UEFI version than what is in the
platform spec (2.8 Errata A in EBBR while 2.9 in platform spec), fwiw.
With version 2.0.1 the EBBR switches to UEFI spec 2.9.
See the changelog in
https://github.com/ARM-software/ebbr/blob/main/source/index.rst
Thanks for the pointer. The platform spec, while calling out 2.0.1, has
a link to 2.0.0: https://arm-software.github.io/ebbr/
In this case, it was just not updated in the webpage. I have raised a github issue[1] for that.
If we're going to call out specific versions we should be able to
directly link to the spec that only has that version specified. In this
case, we're pointing to 2.0.0, but it also seems it's not a particular
revision.
RISC-V specific changes were merged in v2.0.1. That's why, it is referred in the platform spec. https://github.com/ARM-software/ebbr/releases/tag/v2.0.1[1] https://github.com/ARM-software/ebbr/issues/88
Implementing those interfaces should be the only requirement if EBBR is
specified, but we're composing requirements from a multitude of sources,
and it's not clear what spec overrides what requirement. i.e. how are
the various specifications supposed to be composed?
As you noted, you are focusing on server OS distros. While not called
out in the platform spec proper, the assumption for the platform spec is
focusing on products that would primarily load OS binary distros?
Is the platform spec also assuming a particular kernel loader? Is the
term 'OS' encompassing requirements for loader and kernel?
I guess I'm confused that the platform spec is calling out specific
protocols that are not required in EBBR (pcie can make sense if it's
required to boot, as EBBR dictates, but that's not necessarily true
depending on the topology of the system for booting). e.g. why
is EFI_LOAD_FILE2_PROTOCOL included?
EFI_LOAD_FILE_PROTOCOL says "The Load File protocol is used to obtain
files, that are primarily boot options, from arbitrary devices."
EFI_LOAD_FILE2_PROTOCOL says "The Load File 2 protocol is used to obtain
files from arbitrary devices that are not boot options."
The former is not required, but the latter is. How come? The boot service LoadImage() is required via the
EFI_LOAD_FILE_PROTOCOL
and EFI_LOAD_FILE2_PROTOCOL according to the UEFI specification. This
is
implemented in U-Boot and EDK II.
Requiring implementing the EFI_LOAD_FILE2_PROTOCOL in the sense of
offering a file inside the firmware does not make any sense without
specifying which file shall be presented.
The EFI_LOAD_FILE2_PROTOCOL requirement needs some clarification in
the
specification.
Best regards
Heinrich
Regards
Sunil
>
>
> >
> > Conformance with the UEFI platform initialization
specification
is not
> > required.
> >
> > The UEFI API provides standardized means
> >
> > * to boot an operating system
> > * to update the firmware
> > * to reset and power-off
> >
>
> Through the use of runtime services and boot services interfaces,
correct?
>
>
> >
> > For the operating system the standardized API allows:
> >
> > * to create a single installation medium to boot on all
supported RISC-V
> > systems
> > * receive platform information in a system independent
way (via
> > devicetree or ACPI tables)
> > * to implement operating system updates in a system independent
manner
> >
>
> I'm pretty sure those items don't require UEFI.
>
>
> >
> > For the system owner the standardized API allows:
> >
> > * to install alternative operating systems without hassle
> > * easily setup dual boot systems
> >
>
> So the platform spec is not just for OS interfacing with. It's also
> mandating end-user requirements. Who is the end-user? In my
experience, I
> think what you wrote is valid depending on the user. In other
situations it
> is not valid because those requirements do not exist, and they
insist on
> not having UEFI implementations in the firmware.
>
> I think we need to clearly lay out the underlying intention and
not dictate
> how such a thing is followed. Or we acknowledge and clearly
define who the
> end-user is and the assumption in how they would use the product
itself.
>
> -Aaron
>
>
>
>
>
-- Regards, Atish
|
|
|
On Wed, 2021-10-13 at 09:54 -0600, Aaron Durbin wrote:
On Wed, Oct 13, 2021 at 9:50 AM Jonathan Behrens <behrensj@...>
wrote:
3. PMPs - I believe this is an M-mode intention to protect m-
mode assets. Why is an implementation being mandated instead of
requesting M-mode asset protection from the harts? Moreover,
there
doesn't appear to be a requirement that protects M-mode assets
from
I/O agents.
Note that the current RV architecture (other than things like AIA, Debug, and E-Trace) is "CPU" architecture. Things like
IOPMP
and IOMMU will address the needs around I/O agents in a system
(including equivalents to CPU PMAs and PMPs).
So the spec doesn't address m-mode asset protection fully, but it
decided to focus on "cpu" and force an implementation? I
understand the distinction between hart and !hart, but I don't
see the point of requiring PMP specifically. What should be in
the spec is the intention: provide a mechanism to protect m-mode
assets from hart access as well as I/O agents.
The spec requires PMP so that standard M-mode software like OpenSBI
can assume that PMP is implemented. If the requirement was "PMP or
any other asset protection implementation" then OpenSBI would need
to have special handling for every different possible
implementation. I'd also point out that PMP isn't just for
defending against malicious code, it also protects against buggy
code accidentally corrupting M-mode memory.
OpenSBI implementation already has platform specific code in it. PMP,
as specified, is not conducive to all designs. It has power and
performance implications that can be onerous depending on what one is
optimizing for. Is the platform spec trying to protect the OpenSBI
software project?
Obviously not. PMP is the only standard method for protecting M-mode runtime code specified by ISA. That's why, it is mandated in platform spec and OpenSBI uses it. If the RISC-V allows any other standard mechanism in future, OpenSBI will support it. E.g. There were some discussion supporting ePMP in OpenSBI. However, there are no usecase for that as of now. That's why it is not implemented yet. Same is applicable for platform spec. Similar to interrupt controller options, the platform spec is open to have multiple options to protect M-mode implementation. It's just that we don't any other standard option defined by the spec.
Jonathan
On Wed, Oct 13, 2021 at 11:21 AM Aaron Durbin via lists.riscv.org <
adurbin=rivosinc.com@...> wrote:
On Tue, Oct 12, 2021 at 9:51 PM Greg Favor <
gfavor@...> wrote:
On Tue, Oct 12, 2021 at 2:23 PM Aaron Durbin <
adurbin@...> wrote:
1. Zam required, but as far as I can see there is no plan for
ratification in the current items on the docket for
ratification.
Both Zam and Ztso are not yet ratified standards - which is
going to start to be rectified soon.
What's the plan for soon? And what is the definition of soon?
It's not in the list of things to be standardized this Fall. It
would be good to have visibility on these fronts.
1. ACLINT - why is this required? This is forcing an
implementation to use that when it's not necessarily needed.
Keep in mind that it is not as simple as saying that "ACLINT is
required". The OS-A Base spec provides four options for what a
system implements as far as interrupt control.
The 2.1.4.1. Timer support section states "One or more ACLINT
MTIMER devices are required for the OS-A platform"
Is the MTIMER device inclusive of the MTIME register and the set
of MTIMECMP register sets? And what is the thinking here along
with Sstc extension?
I'm looking for more clarity in the spec that constitutes 'ACLINT
MTIMER devices'. Perhaps we should link to a particular section
such as
https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc#2-machine-level-timer-device-mtimer
It might even be worth separating the MTIMER device from the
ACLINT spec itself since the requirement above is standalone.
In RISC-V there have been two de facto standards (PLIC and
CLINT) that were never properly established as official RV
standards but are used by many people - which is in the process
of being addressed. ACLINT is part of the effort to
standardize the existing CLINT, provide more flexibility to
CLINT implementations, and to add on the SSWI part that mirrors
the existing MSWI part (for systems that don't want or need to
implement AIA).
Thank you for the history.
2. APLIC - Same question as ACLINT? Relatedly, why are wired
IRQs called out as being necessary and supported by way of an
APLIC? Why can't wired IRQs be supported in another way?
The Base platform supports use of PLIC, ACLINT, and AIA (and
its IMSIC and APLIC parts). It is not requiring that all OS-A
Base compliant systems implement APLIC (or any part of AIA).
But there is no option to not implement an APLIC or PLIC,
correct? Why not? IMSIC on its own is certainly valid.
For supporting wired interrupts one has two choices - PLIC and
APLIC. (And within RISC-V there will also be CLIC for more
embedded-oriented designs.)
Why just those two? And are these wired interrupts internal to a
part or external? Why couldn't one implement a different way to
generate IRQs from an external wire? That is definitely dictating
product implementation.
And where does this 'wired IRQ' requirement come from exactly?
There's seems to be some implied assumptions, but they are not
clear what that section is trying to address.
3. PMPs - I believe this is an M-mode intention to protect m-
mode assets. Why is an implementation being mandated instead
of requesting M-mode asset protection from the harts?
Moreover, there doesn't appear to be a requirement that
protects M-mode assets from I/O agents.
Note that the current RV architecture (other than things like
AIA, Debug, and E-Trace) is "CPU" architecture. Things like
IOPMP and IOMMU will address the needs around I/O agents in a
system (including equivalents to CPU PMAs and PMPs).
So the spec doesn't address m-mode asset protection fully, but it
decided to focus on "cpu" and force an implementation? I
understand the distinction between hart and !hart, but I don't
see the point of requiring PMP specifically. What should be in
the spec is the intention: provide a mechanism to protect m-mode
assets from hart access as well as I/O agents.
-Aaron
-- Regards, Atish
|
|
|
On Wed, Oct 13, 2021 at 07:43:33PM +0200, Heinrich Schuchardt wrote: On 10/13/21 18:49, Aaron Durbin wrote:
On Wed, Oct 13, 2021 at 9:54 AM Sunil V L <sunilvl@...
<mailto:sunilvl@...>> wrote:
Hi Aaron,
On Wed, Oct 13, 2021 at 09:00:49AM -0600, Aaron Durbin wrote:
> On Tue, Oct 12, 2021 at 9:28 PM Heinrich Schuchardt <
> heinrich.schuchardt@...
<mailto:heinrich.schuchardt@...>> wrote:
>
> >
> >
> > On 10/12/21 23:23, Aaron Durbin wrote:
> > > Hi,
> > >
> > > After reading through the platform spec I have some feedback
on the
> > > technical side of things (different from the scoping of
intention in my
> > > general feedback email).
> > >
> > > 1. Zam required, but as far as I can see there is no plan for
> > > ratification in the current items on the docket for ratification.
> > > 2. Unified Discovery is still up in the air, and it's not clear
> > > exactly the scope of the problem that it is trying to solve.
There's
> > > both debug and runtime use cases, but there are issues about
dynamic
> > > encoding based on fusing, runtime options, even when the
mconfigptr is
> > > valid, etc. In other words, not everything is fully fleshed
out to
> > > mandate such a thing, imo.
> > > 3. On the server extension, it seems to be implied that UEFI
firmware is
> > > mandated despite the OS only needing runtime services. What's
the reason
> > > for forcing a system integrator to use UEFI? And why does it
matter what
> > > firmware is used to the OS?
> >
> > It is not only for the server extension but for all profile
OS-A systems
> > that the platform specification requires the implementation of
as subset
> > of the UEFI API.
> >
> > The specification does not require any specific firmware. Open
source
> > implementations exist with EDK II and U-Boot.
> >
>
> OS-A doesn't indicate much w.r.t. UEFI aside from use UEFI
interface from
> the OS. Server extension mandates implementing large pieces of
UEFI spec:
OS-A refers to EBBR which mandates reduced set of UEFI interfaces.
>
> "The boot and system firmware for the server platforms must
support UEFI as
> defined in the section 2.6 of the UEFI Specification ..."
>
> That indicates implementing UEFI and subsequently dictates other
protocols.
> Therefore, implementing UEFI is inherently mandated.
Yes, UEFI is mandatory for server OS distros. What "other protocols"
which you think not necessary to support server OSs?
The EBBR is required currently to be implemented/presented. It
transitively requires a different UEFI version than what is in the
platform spec (2.8 Errata A in EBBR while 2.9 in platform spec), fwiw.
With version 2.0.1 the EBBR switches to UEFI spec 2.9.
See the changelog in
https://github.com/ARM-software/ebbr/blob/main/source/index.rst
Implementing those interfaces should be the only requirement if EBBR is
specified, but we're composing requirements from a multitude of sources,
and it's not clear what spec overrides what requirement. i.e. how are
the various specifications supposed to be composed?
As you noted, you are focusing on server OS distros. While not called
out in the platform spec proper, the assumption for the platform spec is
focusing on products that would primarily load OS binary distros?
Is the platform spec also assuming a particular kernel loader? Is the
term 'OS' encompassing requirements for loader and kernel?
I guess I'm confused that the platform spec is calling out specific
protocols that are not required in EBBR (pcie can make sense if it's
required to boot, as EBBR dictates, but that's not necessarily true
depending on the topology of the system for booting). e.g. why
is EFI_LOAD_FILE2_PROTOCOL included?
EFI_LOAD_FILE_PROTOCOL says "The Load File protocol is used to obtain
files, that are primarily boot options, from arbitrary devices."
EFI_LOAD_FILE2_PROTOCOL says "The Load File 2 protocol is used to obtain
files from arbitrary devices that are not boot options."
The former is not required, but the latter is. How come? The boot service LoadImage() is required via the EFI_LOAD_FILE_PROTOCOL and
EFI_LOAD_FILE2_PROTOCOL according to the UEFI specification. This is
implemented in U-Boot and EDK II.
Requiring implementing the EFI_LOAD_FILE2_PROTOCOL in the sense of offering
a file inside the firmware does not make any sense without specifying which
file shall be presented.
The EFI_LOAD_FILE2_PROTOCOL requirement needs some clarification in the
specification. EFI_LOAD_FILE2_PROTOCOL is typically used to load from PCIe OptionROM apart from other use cases like loading from RAM. Since we are mandating PCIe, we added this requirement. We can add the clarification. BTW, this is mandatory in SBBR also for the same reasons of PCIe. Is that the only concern, Aaron? Specific examples like this will help to refine the things. Regards Sunil
Best regards
Heinrich
Regards
Sunil
>
>
> >
> > Conformance with the UEFI platform initialization specification
is not
> > required.
> >
> > The UEFI API provides standardized means
> >
> > * to boot an operating system
> > * to update the firmware
> > * to reset and power-off
> >
>
> Through the use of runtime services and boot services interfaces,
correct?
>
>
> >
> > For the operating system the standardized API allows:
> >
> > * to create a single installation medium to boot on all
supported RISC-V
> > systems
> > * receive platform information in a system independent way (via
> > devicetree or ACPI tables)
> > * to implement operating system updates in a system independent
manner
> >
>
> I'm pretty sure those items don't require UEFI.
>
>
> >
> > For the system owner the standardized API allows:
> >
> > * to install alternative operating systems without hassle
> > * easily setup dual boot systems
> >
>
> So the platform spec is not just for OS interfacing with. It's also
> mandating end-user requirements. Who is the end-user? In my
experience, I
> think what you wrote is valid depending on the user. In other
situations it
> is not valid because those requirements do not exist, and they
insist on
> not having UEFI implementations in the firmware.
>
> I think we need to clearly lay out the underlying intention and
not dictate
> how such a thing is followed. Or we acknowledge and clearly
define who the
> end-user is and the assumption in how they would use the product
itself.
>
> -Aaron
>
>
>
>
>
|
|
|
On Wed, Oct 13, 2021 at 8:54 AM Aaron Durbin < adurbin@...> wrote: OpenSBI implementation already has platform specific code in it. PMP, as specified, is not conducive to all designs. It has power and performance implications that can be onerous depending on what one is optimizing for. Is the platform spec trying to protect the OpenSBI software project?
I wrote the following in parallel with Atish writing his response. We're both saying similar things...
PMP (and ePMP) are the only RV standards for M-mode to protect itself from non-M-mode (and to protect M-mode from itself). People are free to do non-standard things and to implement corresponding non-standard software support. But RV efforts to enable portable software need to leverage standardized things.
To say the obvious, anyone is free to come forward and propose/pursue creation of a TG to develop an alternative standard in this or any area.
PMP/ePMP serve to protect various pieces of M-mode software, an SBI implementation (such as OpenSBI) being one. With PMP, all M-mode software is protected from non-M-mode software. With ePMP, parts of M-mode software can be protected from other parts.
PMP is also a basis for implementing broader "TrustZone"-like capabilities, although RV's approach actually supports multiple secure and non-secure domains (unlike TZ). Some commercial TEE products use PMP for this purpose (and provide a multi-domain capability). Some multi-domain exploratory/development efforts in the community are also leveraging PMP.
Greg
|
|
|
On Wed, 2021-10-13 at 09:20 -0600, Aaron Durbin wrote:
On Tue, Oct 12, 2021 at 9:51 PM Greg Favor <gfavor@...>
wrote:
On Tue, Oct 12, 2021 at 2:23 PM Aaron Durbin <adurbin@...>
wrote:
1. Zam required, but as far as I can see there is no plan for
ratification in the current items on the docket for ratification.
Both Zam and Ztso are not yet ratified standards - which is going
to start to be rectified soon.
What's the plan for soon? And what is the definition of soon? It's
not in the list of things to be standardized this Fall. It would be
good to have visibility on these fronts.
1. ACLINT - why is this required? This is forcing an
implementation to use that when it's not necessarily needed.
Keep in mind that it is not as simple as saying that "ACLINT is
required". The OS-A Base spec provides four options for what a
system implements as far as interrupt control.
The 2.1.4.1. Timer support section states "One or more ACLINT MTIMER
devices are required for the OS-A platform"
Is the MTIMER device inclusive of the MTIME register and the set of
MTIMECMP register sets? And what is the thinking here along with Sstc
extension?
I'm looking for more clarity in the spec that constitutes 'ACLINT
MTIMER devices'. Perhaps we should link to a particular section such
as
https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc#2-machine-level-timer-device-mtimer
It might even be worth separating the MTIMER device from the ACLINT
spec itself since the requirement above is standalone.
ACLINT is a modular spec. It allows flexibility in implementing all three (MSWI/SSWI/MTIMER) devices. That's why, a platform can implement only MTIMER. In fact, server extension mandates only the last option where only MTIMER is mandatory. Both M-mode/S-mode software interrupts must be managed by IMSIC. The interrupt & timer table clearly lays out these options. We can add some text to "2.1.4.2.4. MSIs, Virtual MSIs, and Wired IRQs" if required as well.
In RISC-V there have been two de facto standards (PLIC and CLINT)
that were never properly established as official RV standards but
are used by many people - which is in the process of being
addressed. ACLINT is part of the effort to standardize the
existing CLINT, provide more flexibility to CLINT implementations,
and to add on the SSWI part that mirrors the existing MSWI part
(for systems that don't want or need to implement AIA).
Thank you for the history.
2. APLIC - Same question as ACLINT? Relatedly, why are wired IRQs
called out as being necessary and supported by way of an APLIC?
Why can't wired IRQs be supported in another way?
The Base platform supports use of PLIC, ACLINT, and AIA (and its
IMSIC and APLIC parts). It is not requiring that all OS-A Base
compliant systems implement APLIC (or any part of AIA).
But there is no option to not implement an APLIC or PLIC, correct?
Why not? IMSIC on its own is certainly valid.
Yes. Platform spec just providing all the options. Wired irqs can only be generated using APLIC or PLIC while MSIs through IMSIC. That's why, platform spec provides that guidance. If a Platform only wants rely on MSIs for everything, it is okay to implement just IMSIC. That's why, server extension only mandates 2.1.4.2.4. MSIs, Virtual MSIs, and Wired IRQs which states "One, or more AIA APLIC devices are required to support wired interrupts." APLIC can be ignored in case there are no wired irq interrupts in the system. We can certainly improve the text if it is not clear.
For supporting wired interrupts one has two choices - PLIC and
APLIC. (And within RISC-V there will also be CLIC for more
embedded-oriented designs.)
Why just those two? And are these wired interrupts internal to a part
or external? Why couldn't one implement a different way to generate
IRQs from an external wire? That is definitely dictating product
implementation.
And where does this 'wired IRQ' requirement come from exactly?
There's seems to be some implied assumptions, but they are not clear
what that section is trying to address.
3. PMPs - I believe this is an M-mode intention to protect m-mode
assets. Why is an implementation being mandated instead of
requesting M-mode asset protection from the harts? Moreover,
there doesn't appear to be a requirement that protects M-mode
assets from I/O agents.
Note that the current RV architecture (other than things like AIA,
Debug, and E-Trace) is "CPU" architecture. Things like IOPMP and
IOMMU will address the needs around I/O agents in a system
(including equivalents to CPU PMAs and PMPs).
So the spec doesn't address m-mode asset protection fully, but it
decided to focus on "cpu" and force an implementation? I understand
the distinction between hart and !hart, but I don't see the point of
requiring PMP specifically. What should be in the spec is the
intention: provide a mechanism to protect m-mode assets from hart
access as well as I/O agents.
-Aaron
-- Regards, Atish
|
|
|
On Wed, 2021-10-13 at 19:43 +0200, Heinrich Schuchardt wrote: On 10/13/21 18:49, Aaron Durbin wrote:
On Wed, Oct 13, 2021 at 9:54 AM Sunil V L
<sunilvl@...
<mailto:sunilvl@...>> wrote:
Hi Aaron,
On Wed, Oct 13, 2021 at 09:00:49AM -0600, Aaron Durbin wrote:
> On Tue, Oct 12, 2021 at 9:28 PM Heinrich Schuchardt <
> heinrich.schuchardt@...
<mailto:heinrich.schuchardt@...>> wrote:
>
> >
> >
> > On 10/12/21 23:23, Aaron Durbin wrote:
> > > Hi,
> > >
> > > After reading through the platform spec I have some
feedback
on the
> > > technical side of things (different from the scoping of
intention in my
> > > general feedback email).
> > >
> > > 1. Zam required, but as far as I can see there is no
plan for
> > > ratification in the current items on the docket for
ratification.
> > > 2. Unified Discovery is still up in the air, and it's
not clear
> > > exactly the scope of the problem that it is trying to
solve.
There's
> > > both debug and runtime use cases, but there are issues
about
dynamic
> > > encoding based on fusing, runtime options, even when the
mconfigptr is
> > > valid, etc. In other words, not everything is fully
fleshed
out to
> > > mandate such a thing, imo.
> > > 3. On the server extension, it seems to be implied that
UEFI
firmware is
> > > mandated despite the OS only needing runtime services.
What's
the reason
> > > for forcing a system integrator to use UEFI? And why
does it
matter what
> > > firmware is used to the OS?
> >
> > It is not only for the server extension but for all
profile
OS-A systems
> > that the platform specification requires the
implementation of
as subset
> > of the UEFI API.
> >
> > The specification does not require any specific firmware.
Open
source
> > implementations exist with EDK II and U-Boot.
> >
>
> OS-A doesn't indicate much w.r.t. UEFI aside from use UEFI
interface from
> the OS. Server extension mandates implementing large pieces
of
UEFI spec:
OS-A refers to EBBR which mandates reduced set of UEFI
interfaces.
>
> "The boot and system firmware for the server platforms must
support UEFI as
> defined in the section 2.6 of the UEFI Specification ..."
>
> That indicates implementing UEFI and subsequently dictates
other
protocols.
> Therefore, implementing UEFI is inherently mandated.
Yes, UEFI is mandatory for server OS distros. What "other
protocols"
which you think not necessary to support server OSs?
The EBBR is required currently to be implemented/presented. It
transitively requires a different UEFI version than what is in the
platform spec (2.8 Errata A in EBBR while 2.9 in platform spec),
fwiw.
With version 2.0.1 the EBBR switches to UEFI spec 2.9.
See the changelog in
https://github.com/ARM-software/ebbr/blob/main/source/index.rst
Implementing those interfaces should be the only requirement if
EBBR is
specified, but we're composing requirements from a multitude of
sources,
and it's not clear what spec overrides what requirement. i.e. how
are
the various specifications supposed to be composed?
As you noted, you are focusing on server OS distros. While not
called
out in the platform spec proper, the assumption for the platform
spec is
focusing on products that would primarily load OS binary distros?
Is the platform spec also assuming a particular kernel loader? Is
the
term 'OS' encompassing requirements for loader and kernel?
I guess I'm confused that the platform spec is calling out specific
protocols that are not required in EBBR (pcie can make sense if
it's
required to boot, as EBBR dictates, but that's not necessarily true
depending on the topology of the system for booting). e.g. why
is EFI_LOAD_FILE2_PROTOCOL included?
EFI_LOAD_FILE_PROTOCOL says "The Load File protocol is used to
obtain
files, that are primarily boot options, from arbitrary devices."
EFI_LOAD_FILE2_PROTOCOL says "The Load File 2 protocol is used to
obtain
files from arbitrary devices that are not boot options."
The former is not required, but the latter is. How come? The boot service LoadImage() is required via the
EFI_LOAD_FILE_PROTOCOL
and EFI_LOAD_FILE2_PROTOCOL according to the UEFI specification. This
is
implemented in U-Boot and EDK II.
Requiring implementing the EFI_LOAD_FILE2_PROTOCOL in the sense of
offering a file inside the firmware does not make any sense without
specifying which file shall be presented.
The EFI_LOAD_FILE2_PROTOCOL requirement needs some clarification in
the
specification. Just to add to Heinrich's point, LoadFile2 is the preferred method for loading initrd in RISC-V UEFI implementation as well.
Best regards
Heinrich
Regards
Sunil
>
>
> >
> > Conformance with the UEFI platform initialization
specification
is not
> > required.
> >
> > The UEFI API provides standardized means
> >
> > * to boot an operating system
> > * to update the firmware
> > * to reset and power-off
> >
>
> Through the use of runtime services and boot services
interfaces,
correct?
>
>
> >
> > For the operating system the standardized API allows:
> >
> > * to create a single installation medium to boot on all
supported RISC-V
> > systems
> > * receive platform information in a system independent way
(via
> > devicetree or ACPI tables)
> > * to implement operating system updates in a system
independent
manner
> >
>
> I'm pretty sure those items don't require UEFI.
>
>
> >
> > For the system owner the standardized API allows:
> >
> > * to install alternative operating systems without hassle
> > * easily setup dual boot systems
> >
>
> So the platform spec is not just for OS interfacing with.
It's also
> mandating end-user requirements. Who is the end-user? In my
experience, I
> think what you wrote is valid depending on the user. In
other
situations it
> is not valid because those requirements do not exist, and
they
insist on
> not having UEFI implementations in the firmware.
>
> I think we need to clearly lay out the underlying intention
and
not dictate
> how such a thing is followed. Or we acknowledge and clearly
define who the
> end-user is and the assumption in how they would use the
product
itself.
>
> -Aaron
>
>
>
>
>
-- Regards, Atish
|
|
|
On Wed, Oct 13, 2021 at 8:20 AM Aaron Durbin < adurbin@...> wrote: On Tue, Oct 12, 2021 at 9:51 PM Greg Favor < gfavor@...> wrote: On Tue, Oct 12, 2021 at 2:23 PM Aaron Durbin < adurbin@...> wrote: 1. Zam required, but as far as I can see there is no plan for ratification in the current items on the docket for ratification.
Both Zam and Ztso are not yet ratified standards - which is going to start to be rectified soon.
What's the plan for soon? And what is the definition of soon? It's not in the list of things to be standardized this Fall. It would be good to have visibility on these fronts.
Discussion just started a week or so ago, so a plan is being worked out. Once there is a plan, that can be communicated. Either of these may not get ratified by Summit, but then again profiles and platforms also won't be ratified by then either. But it is tentatively expected that Ztso/Zam can happen before profiles/platforms happen (wrt freeze and ratification). Is the MTIMER device inclusive of the MTIME register and the set of MTIMECMP register sets? And what is the thinking here along with Sstc extension?
The ACLINT spec defines the MTIMER "device" as one of the three parts of the spec. And this is backwards compatible with the "MTIMER" part of CLINT.
The SSWI "device" or part of ACLINT provides direct S-mode IPIs for systems that don't implement AIA.
For an "all AIA" design, there is no need for the MSWI or SSWI parts of ACLINT. Conversely they are provided as an option for non-AIA system designs.
Greg
|
|
|
> Why just those two? And are these wired interrupts internal to a part
> or external? Why couldn't one implement a different way to generate
> IRQs from an external wire? That is definitely dictating product
> implementation.
The architecture doesn't presume a single-cip or multi-die (or even single-package versus multi-socket) system design. "Wired interrupts" are all the wired interrupts in a system that go to the system's interrupt controller (e.g. PLIC or AIA). In PLIC architecture, the PLIC controller takes in a wired interrupts and outputs per-hart M and S level "external interrupt" requests (where "external interrupt" uses the terminology in the Priv architecture). In AIA architecture, the APLIC component takes in wired interrupts and sends them to a targeted hart's IMSIC in "MSI form" instead of as a physical wire. In the process AIA avoids all the arch and uarch complexity of ARM GIC and the various separate buses that must be provided to support communication between the Distributor and the CPU Interfaces. Any RV design can choose to not have any of this extra cruft and to instead just use its existing interconnect to carry AIA interrupt "MSIs" (which are simple memory write transactions).
Regarding alternative ways to handle wired interrupts, an implementor is free to implement a custom solution and associated custom supporting software. But standard software won't understand or support that, and just supports standard ways (i.e. PLIC and APLIC/AIA) to handle wired interrupts.
>
> And where does this 'wired IRQ' requirement come from exactly?
> There's seems to be some implied assumptions, but they are not clear
> what that section is trying to address.
As Atish noted, if a system doesn't have any wired interrupts, then it doesn't have to implement a PLIC or APLIC that isn't going to be used. (That could very well need to be more explicitly stated in the spec.)
>
> >
> So the spec doesn't address m-mode asset protection fully, but it
> decided to focus on "cpu" and force an implementation? I understand
> the distinction between hart and !hart, but I don't see the point of
> requiring PMP specifically. What should be in the spec is the
> intention: provide a mechanism to protect m-mode assets from hart
> access as well as I/O agents.
By the nature of PMP architecture in RISC-V, access control is provided/enforced at the master in a system. So each CPU hart wants PMPs and each I/O master also wants similar (which has not yet been architected and standardized in RISC-V).
Greg
|
|
|
On Wed, 2021-10-13 at 09:54 -0600, Aaron Durbin wrote:
>
>
> On Wed, Oct 13, 2021 at 9:50 AM Jonathan Behrens <behrensj@...>
> wrote:
> > > > > 3. PMPs - I believe this is an M-mode intention to protect m-
> > > mode assets. Why is an implementation being mandated instead of
> > > requesting M-mode asset protection from the harts? Moreover,
> > > there
> > > doesn't appear to be a requirement that protects M-mode assets
> > > from
> > > I/O agents.
> > >
> > > > Note that the current RV architecture (other than things like
> > > AIA, Debug, and E-Trace) is "CPU" architecture. Things like
> > > IOPMP
> > > and IOMMU will address the needs around I/O agents in a system
> > > (including equivalents to CPU PMAs and PMPs).
> > >
> > > So the spec doesn't address m-mode asset protection fully, but it
> > > decided to focus on "cpu" and force an implementation? I
> > > understand the distinction between hart and !hart, but I don't
> > > see the point of requiring PMP specifically. What should be in
> > > the spec is the intention: provide a mechanism to protect m-mode
> > > assets from hart access as well as I/O agents.
> > >
> >
> >
> > The spec requires PMP so that standard M-mode software like OpenSBI
> > can assume that PMP is implemented. If the requirement was "PMP or
> > any other asset protection implementation" then OpenSBI would need
> > to have special handling for every different possible
> > implementation. I'd also point out that PMP isn't just for
> > defending against malicious code, it also protects against buggy
> > code accidentally corrupting M-mode memory.
> >
>
>
> OpenSBI implementation already has platform specific code in it. PMP,
> as specified, is not conducive to all designs. It has power and
> performance implications that can be onerous depending on what one is
> optimizing for. Is the platform spec trying to protect the OpenSBI
> software project?
Obviously not. PMP is the only standard method for protecting M-mode
runtime code specified by ISA. That's why, it is mandated in platform
spec and OpenSBI uses it.
It is a method that has been used and is specified. However, I don't understand the leap from that to a hard requirement. Again, I believe the requirement should be focused on the intention -- not the implementation. As I noted previously, the spec also completely omits protection from I/O agents. I'm not sure how to juggle both of those in my head: 1. Use a specific method for protecting a hart from touching m-mode assets. 2. don't bother specifying protection from an I/O agent.
If the RISC-V allows any other standard mechanism in future, OpenSBI
will support it. E.g. There were some discussion supporting ePMP in
OpenSBI. However, there are no usecase for that as of now. That's why
it is not implemented yet.
Same is applicable for platform spec. Similar to interrupt controller
options, the platform spec is open to have multiple options to protect
M-mode implementation. It's just that we don't any other standard
option defined by the spec.
What is the definition of 'standard' being used here? I'd like to understand the requirements of the existence of a 'standard' and being a requirement in the platform spec. This is separate from the intention topic. But I've also noted the power and performance implications for an entity implementing PMP. Why is that not a concern used in the framework for certain requirements?
>
> >
> > Jonathan
> >
> > On Wed, Oct 13, 2021 at 11:21 AM Aaron Durbin via lists.riscv.org <
> > adurbin=rivosinc.com@...> wrote:
> > >
> > >
> > > On Tue, Oct 12, 2021 at 9:51 PM Greg Favor <
> > > gfavor@...> wrote:
> > > > On Tue, Oct 12, 2021 at 2:23 PM Aaron Durbin <
> > > > adurbin@...> wrote:
> > > > > 1. Zam required, but as far as I can see there is no plan for
> > > > > ratification in the current items on the docket for
> > > > > ratification.
> > > > >
> > > >
> > > >
> > > > Both Zam and Ztso are not yet ratified standards - which is
> > > > going to start to be rectified soon.
> > > >
> > >
> > >
> > > What's the plan for soon? And what is the definition of soon?
> > > It's not in the list of things to be standardized this Fall. It
> > > would be good to have visibility on these fronts.
> > >
> > > >
> > > > > 1. ACLINT - why is this required? This is forcing an
> > > > > implementation to use that when it's not necessarily needed.
> > > > >
> > > >
> > > >
> > > > Keep in mind that it is not as simple as saying that "ACLINT is
> > > > required". The OS-A Base spec provides four options for what a
> > > > system implements as far as interrupt control.
> > > >
> > >
> > >
> > > The 2.1.4.1. Timer support section states "One or more ACLINT
> > > MTIMER devices are required for the OS-A platform"
> > >
> > > Is the MTIMER device inclusive of the MTIME register and the set
> > > of MTIMECMP register sets? And what is the thinking here along
> > > with Sstc extension?
> > >
> > > I'm looking for more clarity in the spec that constitutes 'ACLINT
> > > MTIMER devices'. Perhaps we should link to a particular section
> > > such as
> > > https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc#2-machine-level-timer-device-mtimer
> > > It might even be worth separating the MTIMER device from the
> > > ACLINT spec itself since the requirement above is standalone.
> > >
> > > >
> > > > In RISC-V there have been two de facto standards (PLIC and
> > > > CLINT) that were never properly established as official RV
> > > > standards but are used by many people - which is in the process
> > > > of being addressed. ACLINT is part of the effort to
> > > > standardize the existing CLINT, provide more flexibility to
> > > > CLINT implementations, and to add on the SSWI part that mirrors
> > > > the existing MSWI part (for systems that don't want or need to
> > > > implement AIA).
> > > >
> > >
> > >
> > > Thank you for the history.
> > >
> > > >
> > > > > 2. APLIC - Same question as ACLINT? Relatedly, why are wired
> > > > > IRQs called out as being necessary and supported by way of an
> > > > > APLIC? Why can't wired IRQs be supported in another way?
> > > > >
> > > >
> > > >
> > > > The Base platform supports use of PLIC, ACLINT, and AIA (and
> > > > its IMSIC and APLIC parts). It is not requiring that all OS-A
> > > > Base compliant systems implement APLIC (or any part of AIA).
> > > >
> > >
> > >
> > > But there is no option to not implement an APLIC or PLIC,
> > > correct? Why not? IMSIC on its own is certainly valid.
> > >
> > > >
> > > > For supporting wired interrupts one has two choices - PLIC and
> > > > APLIC. (And within RISC-V there will also be CLIC for more
> > > > embedded-oriented designs.)
> > > >
> > >
> > >
> > > Why just those two? And are these wired interrupts internal to a
> > > part or external? Why couldn't one implement a different way to
> > > generate IRQs from an external wire? That is definitely dictating
> > > product implementation.
> > >
> > > And where does this 'wired IRQ' requirement come from exactly?
> > > There's seems to be some implied assumptions, but they are not
> > > clear what that section is trying to address.
> > >
> > > >
> > > > > 3. PMPs - I believe this is an M-mode intention to protect m-
> > > > > mode assets. Why is an implementation being mandated instead
> > > > > of requesting M-mode asset protection from the harts?
> > > > > Moreover, there doesn't appear to be a requirement that
> > > > > protects M-mode assets from I/O agents.
> > > > >
> > > >
> > > >
> > > > Note that the current RV architecture (other than things like
> > > > AIA, Debug, and E-Trace) is "CPU" architecture. Things like
> > > > IOPMP and IOMMU will address the needs around I/O agents in a
> > > > system (including equivalents to CPU PMAs and PMPs).
> > > >
> > >
> > >
> > > So the spec doesn't address m-mode asset protection fully, but it
> > > decided to focus on "cpu" and force an implementation? I
> > > understand the distinction between hart and !hart, but I don't
> > > see the point of requiring PMP specifically. What should be in
> > > the spec is the intention: provide a mechanism to protect m-mode
> > > assets from hart access as well as I/O agents.
> > >
> > > -Aaron
> > > >
>
--
Regards,
Atish
|
|
|
