Platform Spec Technical Feedback


Aaron Durbin
 



On Wed, Oct 13, 2021 at 12:13 PM Sunil V L <sunilvl@...> wrote:
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.

Personally, I have issues with the security aspects of option roms in practice so we may want to note that this requirement is if one wants to support option roms -- not necessarily a hard requirement.

Thanks for the clarification. I think added reasoning for requirements helps provide context.
 

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
> >      >
> >      >
> >      >
> >      >
> >      >
> >
>


Aaron Durbin
 



On Wed, Oct 13, 2021 at 12:19 PM Greg Favor <gfavor@...> wrote:
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.

What is the definition of standard? And if such a standard has product implications that's ok? I want to understand the rules for making something a requirement. i.e. the framework for deciding what is and isn't put into a hard requirement.
 

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.

Is that a rule for the platform spec? Intention -- but not dictating implementation interface -- is not in the purview of the spec? There are definitely items in there that only cover intention. So when and who is deciding if an implementation is mandated? 


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.

I'm not refuting that people have taken advantage of PMP implementations. I'm noting they are not necessarily the right choice for protecting m-mode assets. And this depends on one's product requirements. How inclusive is the platform spec trying to be in dictating the implementation of products? That's why I'm trying to nail down how one decides to engage the platform spec since clearly there are implicit assumptions of those definitions.

-Aaron


Aaron Durbin
 



On Wed, Oct 13, 2021 at 12:32 PM Atish Patra <atish.patra@...> wrote:
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.


The platform spec states for OS-A: One or more ACLINT MTIMER devices are required for the OS-A platform.

The way I'm reading the ACLINT (is this a standard? is it ratified?) spec it indicates " A MTIMER device not connected to any HART should only have a MTIME register and no MTIMECMP registers." Therefore, MTIMECMP registers are not needed.

Is the intention of the OS-A platform spec to say there's an memory mapped 8 byte register that has an 'Machine-level time counter' with an update frequency of 10 MHz and 100 MHz and a default tick resolution of 10ns?
 
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






Aaron Durbin
 

Sorry. I missed the other update below.

On Wed, Oct 13, 2021 at 12:32 PM Atish Patra <atish.patra@...> wrote:
> 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.

I think that would be helpful because, to me, it reads like wired interrupts are required.


Aaron Durbin
 



On Wed, Oct 13, 2021 at 12:58 PM Greg Favor <gfavor@...> wrote:
On Wed, Oct 13, 2021 at 11:32 AM Atish Patra <Atish.Patra@...> wrote:
> 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.)

Agreed that if the spec is intending to allow it then it should be more explicitly stated.
 
 
>  
> >  
> 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).

What do you mean by 'at the master in a system'? I don't see any mention of 'master' in the PMP section of the spec.

-Aaron


atishp@...
 

On Wed, 2021-10-13 at 14:35 -0600, Aaron Durbin wrote:
Sorry. I missed the other update below.

On Wed, Oct 13, 2021 at 12:32 PM Atish Patra <atish.patra@...>
wrote:
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.

I think that would be helpful because, to me, it reads like wired
interrupts are required.
Sure. We will try to improve the text. Any suggestions are welcome.
Thanks again for your feedback.


--
Regards,
Atish


atishp@...
 

On Wed, 2021-10-13 at 14:15 -0600, Aaron Durbin wrote:


On Wed, Oct 13, 2021 at 12:12 PM Atish Patra <Atish.Patra@...>
wrote:
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. 
That may lead to a lot of fragmentation in terms of implementation in
hardware and software customization. Isn't it ?

Another issue with just specifying the intent is that how do we verify
if a platform is compatible with the specification ? A custom mechanism
to protect higher privilege mode may also motivate the platform vendors
to provide vendor specific locked firmware instead of open firmware.

Having said that, platform spec can definitely relax the PMP
requirement in its future revisions for an alternative scheme that has
a lower power consumption & higher performance requirement.


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.
 
Because there are no current mechanism in RISC-V specification for I/O
protection except IOPMP proposal. I am not sure what's the status of
IOPMP. That can included if the IOPMP specification becomes a reality.
 
If you think adding just the intention here would be helpful, please
suggest something along that lines or send a patch.



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? 
Any specification that is being drafted/frozen/ratified under RVI.
As there are lot of moving pieces as of now, platform spec refers to
other specs that are not frozen yet. But these things has to happen in
parallel to make progress.


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?
  
Let me add some more clarification.

Intention: Protect m-mode run time code. (all of us agree that this
needs to happen)

Current Requirement: PMP is mandated because that is the only mechanism
provided under RV. AFAIK, all the platforms (except ariane) has
implemented PMP while agreeing that it is expensive. Power/Performance
consumption issues are known but there is no alternative.

Any other mechanism should be proposed as an ISA extension so that it
can be standardized and included in platform specification.

It is a separate discussion if we just leave at the intention and not
specify any requirement. I have given my 2 cents about that in the
above paragraph.




 

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


Allen Baum
 

Just to share my 2 <name your favorite minor currency> here: 

The RV architecture is designed to be extremely modular, and has a lot of optional behaviors
This is intended to allow implementation freedom, which is a good thing.
It is also a way that can lead to unmanageable fragmentation - and that is a bad thing. A very bad thing.
It is a tenuous balance.
So, a meta-intent - that leads to other intents - is that we want to provide services without fragmenting the architecture

The platform spec - in this particular case - is mandating a specific iintention (M-mode protection)  use a specific extension .
There are no other extensions that are proposed/drafted/in-review/ratified/ in the architecture that can implement that specific intent. (right now)
     (except ePMP which is completely backwards compatible)
Mandating the use of the only available option sounds like a no-brainer to me.
Note that the PMP spec is highly configurable: how many entries, its granularity, how regions can be defined, and more.
It could even be a fixed, readonly structure. 

If you want to argue that server platforms don't require M-mode protection - I'm not sure you'll find a lot of agreement.
If you want to argue that server platforms should use any form of protection they like (and be declared platforn compatible - ditto.
If you want to argue that server platform fragmentation is a good thing - best of luck.

That doesn't mean that some better definition will come up, or, if it does, won't be incorporated into a revision of the platform spec.
The platform spec is an evolving document, so if you have a better way, you are free to prose it, and if it is judged better, it can be adopted.
Supporting legacy spec is always fraught, but 




On Wed, Oct 13, 2021 at 7:09 PM Atish Patra <atish.patra@...> wrote:
On Wed, 2021-10-13 at 14:15 -0600, Aaron Durbin wrote:
>
>
> On Wed, Oct 13, 2021 at 12:12 PM Atish Patra <Atish.Patra@...>
> wrote:
> > 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. 

That may lead to a lot of fragmentation in terms of implementation in
hardware and software customization. Isn't it ?

Another issue with just specifying the intent is that how do we verify
if a platform is compatible with the specification ? A custom mechanism
to protect higher privilege mode may also motivate the platform vendors
to provide vendor specific locked firmware instead of open firmware.

Having said that, platform spec can definitely relax the PMP
requirement in its future revisions for an alternative scheme that has
a lower power consumption & higher performance requirement.


> 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.
>  

Because there are no current mechanism in RISC-V specification for I/O
protection except IOPMP proposal. I am not sure what's the status of
IOPMP. That can included if the IOPMP specification becomes a reality.
 
If you think adding just the intention here would be helpful, please
suggest something along that lines or send a patch.


> >
> > 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? 

Any specification that is being drafted/frozen/ratified under RVI.
As there are lot of moving pieces as of now, platform spec refers to
other specs that are not frozen yet. But these things has to happen in
parallel to make progress.


> 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?
>   

Let me add some more clarification.

Intention: Protect m-mode run time code. (all of us agree that this
needs to happen)

Current Requirement: PMP is mandated because that is the only mechanism
provided under RV. AFAIK, all the platforms (except ariane) has
implemented PMP while agreeing that it is expensive. Power/Performance
consumption issues are known but there is no alternative.

Any other mechanism should be proposed as an ISA extension so that it
can be standardized and included in platform specification.

It is a separate discussion if we just leave at the intention and not
specify any requirement. I have given my 2 cents about that in the
above paragraph.


> >
> >
> > >  
> > > >
> > > > 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






Aaron Durbin
 



On Wed, Oct 13, 2021 at 8:09 PM Atish Patra <Atish.Patra@...> wrote:
On Wed, 2021-10-13 at 14:15 -0600, Aaron Durbin wrote:

> 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. 

That may lead to a lot of fragmentation in terms of implementation in
hardware and software customization. Isn't it ?

I think there will be fragmentation in the short term because we're building an airplane while flying. Not every solution necessarily meets the needs of every product. While the existence of one solution does not lead to the only solution.
 


Another issue with just specifying the intent is that how do we verify
if a platform is compatible with the specification ? A custom mechanism
to protect higher privilege mode may also motivate the platform vendors
to provide vendor specific locked firmware instead of open firmware.

Yes, that's an issue when one doesn't have scalable solutions already defined and ready to use. However, there are already requirements that recommend or provide intention in the platform spec.
 

Having said that, platform spec can definitely relax the PMP
requirement in its future revisions for an alternative scheme that has
a lower power consumption & higher performance requirement.


> 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.
>  

Because there are no current mechanism in RISC-V specification for I/O
protection except IOPMP proposal. I am not sure what's the status of
IOPMP. That can included if the IOPMP specification becomes a reality.
 
If you think adding just the intention here would be helpful, please
suggest something along that lines or send a patch.

Before I send a patch I would like to get some agreement on the intention of the requirement.  I think the verbiage of machine mode asset protection would be something like:

"It is important that machine mode assets, such as code and data, are protected non-machine mode errant accesses from the harts in the system. Additionally, I/O agent access protection is also required within the system to protect machine mode assets. Therefore, the following requirements are stipulated:
1. Platform must provide a protection mechanism from non-machine mode hart transactions that precisely traps if violated.
1a. If PMP is used for this protection mechanism, at least 4 PMP regions are required for OS-A and 16 PMP regions for OS-A server extension"
2. Platform must provide a protection mechanism from I/O agents manipulating or accessing machine mode assets."

Obviously it's not perfect, and suggestions are welcome, but I do think that covers intent from a specification standpoint w/o providing a false sense of security. It additionally brings in the PMP requirements that are already there, albeit conditionally on implementation choice. What good is hart protection if an I/O agent can stomp all over the machine mode assets?
 


> >
> > 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? 

Any specification that is being drafted/frozen/ratified under RVI.
As there are lot of moving pieces as of now, platform spec refers to
other specs that are not frozen yet. But these things has to happen in
parallel to make progress.

Thank you. I'm not asking you to speak for Greg, but "standard software" is being used as well throughout this thread. Where does the notion of "standard software" fit in?
 


> 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?
>   

Let me add some more clarification.

Intention: Protect m-mode run time code. (all of us agree that this
needs to happen)

Current Requirement: PMP is mandated because that is the only mechanism
provided under RV. AFAIK, all the platforms (except ariane) has
implemented PMP while agreeing that it is expensive. Power/Performance
consumption issues are known but there is no alternative.

To conclude: the platform spec is forcing product sacrifices on other products that wish to adhere to platform spec even in the presence of known deficiencies.
 

Any other mechanism should be proposed as an ISA extension so that it
can be standardized and included in platform specification.

I think we'll send a proposal over for a simplified machine mode protection.
 


It is a separate discussion if we just leave at the intention and not
specify any requirement. I have given my 2 cents about that in the
above paragraph.


> >
> >
> > >  
> > > >
> > > > 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


Aaron Durbin
 



On Wed, Oct 13, 2021 at 9:08 PM Allen Baum <allen.baum@...> wrote:
Just to share my 2 <name your favorite minor currency> here: 

The RV architecture is designed to be extremely modular, and has a lot of optional behaviors
This is intended to allow implementation freedom, which is a good thing.
It is also a way that can lead to unmanageable fragmentation - and that is a bad thing. A very bad thing.
It is a tenuous balance.
So, a meta-intent - that leads to other intents - is that we want to provide services without fragmenting the architecture

Agree on the potential for unmanageable fragmentation which should definitely planned for in preventing.
 

The platform spec - in this particular case - is mandating a specific iintention (M-mode protection)  use a specific extension .

This is a quibble, but I don't see m-mode protection explicitly noted in the platform spec. I see a mandate of PMP, though.
 
There are no other extensions that are proposed/drafted/in-review/ratified/ in the architecture that can implement that specific intent. (right now)
     (except ePMP which is completely backwards compatible)
Mandating the use of the only available option sounds like a no-brainer to me.

Despite the known limitations?
 
Note that the PMP spec is highly configurable: how many entries, its granularity, how regions can be defined, and more.
It could even be a fixed, readonly structure. 

If you want to argue that server platforms don't require M-mode protection - I'm not sure you'll find a lot of agreement.
If you want to argue that server platforms should use any form of protection they like (and be declared platforn compatible - ditto.
If you want to argue that server platform fragmentation is a good thing - best of luck.

I was arguing for not requiring M-mode protection nor that fragmentation is good for the sake of fragmentation. Please point to where I made those claims so I can rectify any misinterpretation. 

What I have been and am suggesting is that PMPs have a heavy cost to particular products so we shouldn't be requiring those in the platform spec.
 

That doesn't mean that some better definition will come up, or, if it does, won't be incorporated into a revision of the platform spec.
The platform spec is an evolving document, so if you have a better way, you are free to prose it, and if it is judged better, it can be adopted.
Supporting legacy spec is always fraught, but 




On Wed, Oct 13, 2021 at 7:09 PM Atish Patra <atish.patra@...> wrote:
On Wed, 2021-10-13 at 14:15 -0600, Aaron Durbin wrote:
>
>
> On Wed, Oct 13, 2021 at 12:12 PM Atish Patra <Atish.Patra@...>
> wrote:
> > 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. 

That may lead to a lot of fragmentation in terms of implementation in
hardware and software customization. Isn't it ?

Another issue with just specifying the intent is that how do we verify
if a platform is compatible with the specification ? A custom mechanism
to protect higher privilege mode may also motivate the platform vendors
to provide vendor specific locked firmware instead of open firmware.

Having said that, platform spec can definitely relax the PMP
requirement in its future revisions for an alternative scheme that has
a lower power consumption & higher performance requirement.


> 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.
>  

Because there are no current mechanism in RISC-V specification for I/O
protection except IOPMP proposal. I am not sure what's the status of
IOPMP. That can included if the IOPMP specification becomes a reality.
 
If you think adding just the intention here would be helpful, please
suggest something along that lines or send a patch.


> >
> > 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? 

Any specification that is being drafted/frozen/ratified under RVI.
As there are lot of moving pieces as of now, platform spec refers to
other specs that are not frozen yet. But these things has to happen in
parallel to make progress.


> 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?
>   

Let me add some more clarification.

Intention: Protect m-mode run time code. (all of us agree that this
needs to happen)

Current Requirement: PMP is mandated because that is the only mechanism
provided under RV. AFAIK, all the platforms (except ariane) has
implemented PMP while agreeing that it is expensive. Power/Performance
consumption issues are known but there is no alternative.

Any other mechanism should be proposed as an ISA extension so that it
can be standardized and included in platform specification.

It is a separate discussion if we just leave at the intention and not
specify any requirement. I have given my 2 cents about that in the
above paragraph.


> >
> >
> > >  
> > > >
> > > > 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






Greg Favor
 

On Thu, Oct 14, 2021 at 7:04 AM Aaron Durbin <adurbin@...> wrote:
Obviously it's not perfect, and suggestions are welcome, but I do think that covers intent from a specification standpoint w/o providing a false sense of security. It additionally brings in the PMP requirements that are already there, albeit conditionally on implementation choice. What good is hart protection if an I/O agent can stomp all over the machine mode assets?

To probably say the obvious, the current RV arch defines one standard (aka ratified) M-mode protection mechanism for harts, and does not yet define a standard M-mode protection mechanism for I/O agents.  The current IOPMP effort is one effort working to address this (along with other "IOMMU" type issues).  An IOMMU effort should also address this.  (In the latter case, I would argue that the "PMP" part of an IOMMU arch should maximize consistency with the existing PMP part of the CPU arch.  Just as it should maximize consistency with the Priv MMU arch, H, and AIA.  Insofar as when an alternative PMP-like scheme becomes standardized (i.e. ratified), then that will likely also need to reconcile how it fits into both the CPU and IOMMU architectures.)

Greg


 


Aaron Durbin
 



On Thu, Oct 14, 2021 at 12:32 PM Greg Favor <gfavor@...> wrote:
On Thu, Oct 14, 2021 at 7:04 AM Aaron Durbin <adurbin@...> wrote:
Obviously it's not perfect, and suggestions are welcome, but I do think that covers intent from a specification standpoint w/o providing a false sense of security. It additionally brings in the PMP requirements that are already there, albeit conditionally on implementation choice. What good is hart protection if an I/O agent can stomp all over the machine mode assets?

To probably say the obvious, the current RV arch defines one standard (aka ratified) M-mode protection mechanism for harts, and does not yet define a standard M-mode protection mechanism for I/O agents.  The current IOPMP effort is one effort working to address this (along with other "IOMMU" type issues).  An IOMMU effort should also address this.  (In the latter case, I would argue that the "PMP" part of an IOMMU arch should maximize consistency with the existing PMP part of the CPU arch.  Just as it should maximize consistency with the Priv MMU arch, H, and AIA.  Insofar as when an alternative PMP-like scheme becomes standardized (i.e. ratified), then that will likely also need to reconcile how it fits into both the CPU and IOMMU architectures.)

Greg, were you answering "What good is hart protection if an I/O agent can stomp all over the machine mode assets?"? If so, what you described doesn't seem to address that question directly. This falls into the security pieces of the platform spec in that people were wanting to signal "risc-v cares about security". Now we're specifying things related to m-mode asset protection (though not explicitly stated in the spec) and omitting protection from I/O agent tampering. That construction inherently leaves a hole w.r.t. m-mode asset protection.

If I put an operator's hat on, that situation doesn't give me the warm fuzzies nor would I lend credence to the platform spec taking full consideration of these aspects. All because there isn't yet a ratified M-mode protection mechanism for I/O agents?

-Aaron

-Aaron


Greg Favor
 

On Thu, Oct 14, 2021 at 7:15 AM Aaron Durbin <adurbin@...> wrote:
What I have been and am suggesting is that PMPs have a heavy cost to particular products so we shouldn't be requiring those in the platform spec.

In practice, most of the RV community doesn't share this view.  Certainly there are implementations that choose to not have any PMP or to have a small number of PMPs or to have a bunch that are hardwired (as ways to limit the cost).  For Rich O/S (e.g. Linux) systems, the cost of a few PMPs is peanuts in the overall scheme of things (and security is a growing issue in the industry).  Conversely, non-Rich O/S systems have different platform spec they can conform to that doesn't require any PMP (i.e. the base M platform, although there is also going to be a security-oriented M platform extension that not surprisingly requires PMP).  In general, RV is gradually taking security more seriously with various TG efforts in various stages of progress.

And just to note:  None of this intrinsically prevents development and standardization of a second "M-mode protection" scheme that could be referenced and used by subsequent platform specs.

Greg

 


Jonathan Behrens <behrensj@...>
 

There are no other extensions that are proposed/drafted/in-review/ratified/ in the architecture that can implement that specific intent. (right now)
     (except ePMP which is completely backwards compatible)
Mandating the use of the only available option sounds like a no-brainer to me.

Despite the known limitations?

I don't think there's broad agreement that PMP has significant limitations. Do you have pointers to any work showing that an alternative approach would be substantially cheaper? For instance, for the server platform, I have a hard time imagining that it amounts to anything more than a rounding error in the total cost. Servers can cost thousands of dollars!

Out of curiosity, do you have a system you're designing that uses a custom alternative to PMP?

Jonathan



On Thu, Oct 14, 2021 at 10:16 AM Aaron Durbin <adurbin@...> wrote:


On Wed, Oct 13, 2021 at 9:08 PM Allen Baum <allen.baum@...> wrote:
Just to share my 2 <name your favorite minor currency> here: 

The RV architecture is designed to be extremely modular, and has a lot of optional behaviors
This is intended to allow implementation freedom, which is a good thing.
It is also a way that can lead to unmanageable fragmentation - and that is a bad thing. A very bad thing.
It is a tenuous balance.
So, a meta-intent - that leads to other intents - is that we want to provide services without fragmenting the architecture

Agree on the potential for unmanageable fragmentation which should definitely planned for in preventing.
 

The platform spec - in this particular case - is mandating a specific iintention (M-mode protection)  use a specific extension .

This is a quibble, but I don't see m-mode protection explicitly noted in the platform spec. I see a mandate of PMP, though.
 
There are no other extensions that are proposed/drafted/in-review/ratified/ in the architecture that can implement that specific intent. (right now)
     (except ePMP which is completely backwards compatible)
Mandating the use of the only available option sounds like a no-brainer to me.

Despite the known limitations?
 
Note that the PMP spec is highly configurable: how many entries, its granularity, how regions can be defined, and more.
It could even be a fixed, readonly structure. 

If you want to argue that server platforms don't require M-mode protection - I'm not sure you'll find a lot of agreement.
If you want to argue that server platforms should use any form of protection they like (and be declared platforn compatible - ditto.
If you want to argue that server platform fragmentation is a good thing - best of luck.

I was arguing for not requiring M-mode protection nor that fragmentation is good for the sake of fragmentation. Please point to where I made those claims so I can rectify any misinterpretation. 

What I have been and am suggesting is that PMPs have a heavy cost to particular products so we shouldn't be requiring those in the platform spec.
 

That doesn't mean that some better definition will come up, or, if it does, won't be incorporated into a revision of the platform spec.
The platform spec is an evolving document, so if you have a better way, you are free to prose it, and if it is judged better, it can be adopted.
Supporting legacy spec is always fraught, but 




On Wed, Oct 13, 2021 at 7:09 PM Atish Patra <atish.patra@...> wrote:
On Wed, 2021-10-13 at 14:15 -0600, Aaron Durbin wrote:
>
>
> On Wed, Oct 13, 2021 at 12:12 PM Atish Patra <Atish.Patra@...>
> wrote:
> > 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. 

That may lead to a lot of fragmentation in terms of implementation in
hardware and software customization. Isn't it ?

Another issue with just specifying the intent is that how do we verify
if a platform is compatible with the specification ? A custom mechanism
to protect higher privilege mode may also motivate the platform vendors
to provide vendor specific locked firmware instead of open firmware.

Having said that, platform spec can definitely relax the PMP
requirement in its future revisions for an alternative scheme that has
a lower power consumption & higher performance requirement.


> 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.
>  

Because there are no current mechanism in RISC-V specification for I/O
protection except IOPMP proposal. I am not sure what's the status of
IOPMP. That can included if the IOPMP specification becomes a reality.
 
If you think adding just the intention here would be helpful, please
suggest something along that lines or send a patch.


> >
> > 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? 

Any specification that is being drafted/frozen/ratified under RVI.
As there are lot of moving pieces as of now, platform spec refers to
other specs that are not frozen yet. But these things has to happen in
parallel to make progress.


> 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?
>   

Let me add some more clarification.

Intention: Protect m-mode run time code. (all of us agree that this
needs to happen)

Current Requirement: PMP is mandated because that is the only mechanism
provided under RV. AFAIK, all the platforms (except ariane) has
implemented PMP while agreeing that it is expensive. Power/Performance
consumption issues are known but there is no alternative.

Any other mechanism should be proposed as an ISA extension so that it
can be standardized and included in platform specification.

It is a separate discussion if we just leave at the intention and not
specify any requirement. I have given my 2 cents about that in the
above paragraph.


> >
> >
> > >  
> > > >
> > > > 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






Aaron Durbin
 



On Thu, Oct 14, 2021 at 12:44 PM Greg Favor <gfavor@...> wrote:
On Thu, Oct 14, 2021 at 7:15 AM Aaron Durbin <adurbin@...> wrote:
What I have been and am suggesting is that PMPs have a heavy cost to particular products so we shouldn't be requiring those in the platform spec.

In practice, most of the RV community doesn't share this view.  Certainly there are implementations that choose to not have any PMP or to have a small number of PMPs or to have a bunch that are hardwired (as ways to limit the cost).  For Rich O/S (e.g. Linux) systems, the cost of a few PMPs is peanuts in the overall scheme of things (and security is a growing issue in the industry).  Conversely, non-Rich O/S systems have different platform spec they can conform to that doesn't require any PMP (i.e. the base M platform, although there is also going to be a security-oriented M platform extension that not surprisingly requires PMP).  In general, RV is gradually taking security more seriously with various TG efforts in various stages of progress.

Because most of the current RV community doesn't share this view doesn't mean a counter view is correct. Would you agree?

On what dimension is your assessment that a few PMPs are peanuts? Performance? Power? And what number of PMPs? I would like to hear about the assumptions made in that assessment w.r.t power, clock targets, etc. Obviously those dimensions are things people are defining for their own products.


And just to note:  None of this intrinsically prevents development and standardization of a second "M-mode protection" scheme that could be referenced and used by subsequent platform specs.

Greg

 


Greg Favor
 

On Thu, Oct 14, 2021 at 11:43 AM Aaron Durbin <adurbin@...> wrote:
To probably say the obvious, the current RV arch defines one standard (aka ratified) M-mode protection mechanism for harts, and does not yet define a standard M-mode protection mechanism for I/O agents.  The current IOPMP effort is one effort working to address this (along with other "IOMMU" type issues).  An IOMMU effort should also address this.  (In the latter case, I would argue that the "PMP" part of an IOMMU arch should maximize consistency with the existing PMP part of the CPU arch.  Just as it should maximize consistency with the Priv MMU arch, H, and AIA.  Insofar as when an alternative PMP-like scheme becomes standardized (i.e. ratified), then that will likely also need to reconcile how it fits into both the CPU and IOMMU architectures.)

Greg, were you answering "What good is hart protection if an I/O agent can stomp all over the machine mode assets?"? If so, what you described doesn't seem to address that question directly. This falls into the security pieces of the platform spec in that people were wanting to signal "risc-v cares about security". Now we're specifying things related to m-mode asset protection (though not explicitly stated in the spec) and omitting protection from I/O agent tampering. That construction inherently leaves a hole w.r.t. m-mode asset protection.

I'm not disagreeing with the point that there also needs to be protection from non-hart masters in a system (aka I/O agents).  I was just pointing out that RV so far has only addressed half of the overall picture, i.e. the CPU agent side.  And that existing/new efforts like IOPMP and IOMMU need to fill in the other side.

Once there is/are suitable (ratified) standard(s) for doing this, updated platform specs can incorporate them.  But in the meantime the initial platform specs can only stay silent or can express a very high-level requirement for some implementation-specific form of mechanism.  (I can see arguments for and against both approaches.)  This is similar to the situation with things like RAS, IOMMU, and several security areas - for which the initial OS-A and M Base platforms stay silent while RVI efforts work to fill in these holes.
 
Greg


Aaron Durbin
 



On Thu, Oct 14, 2021 at 12:59 PM Greg Favor <gfavor@...> wrote:
On Thu, Oct 14, 2021 at 11:43 AM Aaron Durbin <adurbin@...> wrote:
To probably say the obvious, the current RV arch defines one standard (aka ratified) M-mode protection mechanism for harts, and does not yet define a standard M-mode protection mechanism for I/O agents.  The current IOPMP effort is one effort working to address this (along with other "IOMMU" type issues).  An IOMMU effort should also address this.  (In the latter case, I would argue that the "PMP" part of an IOMMU arch should maximize consistency with the existing PMP part of the CPU arch.  Just as it should maximize consistency with the Priv MMU arch, H, and AIA.  Insofar as when an alternative PMP-like scheme becomes standardized (i.e. ratified), then that will likely also need to reconcile how it fits into both the CPU and IOMMU architectures.)

Greg, were you answering "What good is hart protection if an I/O agent can stomp all over the machine mode assets?"? If so, what you described doesn't seem to address that question directly. This falls into the security pieces of the platform spec in that people were wanting to signal "risc-v cares about security". Now we're specifying things related to m-mode asset protection (though not explicitly stated in the spec) and omitting protection from I/O agent tampering. That construction inherently leaves a hole w.r.t. m-mode asset protection.

I'm not disagreeing with the point that there also needs to be protection from non-hart masters in a system (aka I/O agents).  I was just pointing out that RV so far has only addressed half of the overall picture, i.e. the CPU agent side.  And that existing/new efforts like IOPMP and IOMMU need to fill in the other side.

Once there is/are suitable (ratified) standard(s) for doing this, updated platform specs can incorporate them.  But in the meantime the initial platform specs can only stay silent or can express a very high-level requirement for some implementation-specific form of mechanism.  (I can see arguments for and against both approaches.)  This is similar to the situation with things like RAS, IOMMU, and several security areas - for which the initial OS-A and M Base platforms stay silent while RVI efforts work to fill in these holes.

That was why I suggested language that expressed that high-level requirement for that purpose of covering the bases of known gaps. Teh point of the platform spec is to provide a target for an ecosystem, but it's also being positioned to express that risc-v has these ttypes of things covered. If not, the brand recognition of the platform spec can be undermined. If I am wrong in the platform spec trying to serve both purposes please let me know as that is exactly how the secure boot topic came about. "We need to say something about security in 2022."

-Aaron


Greg Favor
 

On Thu, Oct 14, 2021 at 11:56 AM Aaron Durbin <adurbin@...> wrote:
Because most of the current RV community doesn't share this view doesn't mean a counter view is correct. Would you agree?

Invariably, with the breadth of the RV community, there is the whole spectrum of views.  Which is why RV arch is modular and has lots of optionality, and why there will be multiple profiles and platform (and growing over time).  No one thing can cater to everyone.  The topic of "IOMMU" is an example.  Embedded-oriented and enterprise-class IOMMUs want to be very different animals (as we'll likely see with coming IOPMP and IOMMU standards).


On what dimension is your assessment that a few PMPs are peanuts? Performance? Power? And what number of PMPs? I would like to hear about the assumptions made in that assessment w.r.t power, clock targets, etc. Obviously those dimensions are things people are defining for their own products.

Everyone will judge this differently, but the people doing cost-sensitive designs that care about security don't find a few PMPs to be a significant performance or power issue (and they tend to have a small number of PMPs).  But even within that arena, people differ in what they want and what they are willing to implement, i.e. there isn't a simple cut-and-dried answer.

Greg


Greg Favor
 

On Thu, Oct 14, 2021 at 12:03 PM Aaron Durbin <adurbin@...> wrote:
Once there is/are suitable (ratified) standard(s) for doing this, updated platform specs can incorporate them.  But in the meantime the initial platform specs can only stay silent or can express a very high-level requirement for some implementation-specific form of mechanism.  (I can see arguments for and against both approaches.)  This is similar to the situation with things like RAS, IOMMU, and several security areas - for which the initial OS-A and M Base platforms stay silent while RVI efforts work to fill in these holes.

That was why I suggested language that expressed that high-level requirement for that purpose of covering the bases of known gaps. Teh point of the platform spec is to provide a target for an ecosystem, but it's also being positioned to express that risc-v has these ttypes of things covered.

I don't believe people developing the profiles and platforms, as well as Tech Chairs, the TSC, and the board, consider that these things are covered.  If anything, it is the opposite.  (That can certainly be stated explicitly in profile and platform specs.)
 
If not, the brand recognition of the platform spec can be undermined. If I am wrong in the platform spec trying to serve both purposes please let me know as that is exactly how the secure boot topic came about. "We need to say something about security in 2022."

There were arguments back and around this, with a conclusion that the base OS-A and M platforms will remain silent for 2022.  And it is just the Server extension that expresses just a high-level secure boot requirement until RV secure boot standards have been developed that platforms can then mandate; and the Server extension will remain silent on a number of other security topics.

Greg


Aaron Durbin
 



On Thu, Oct 14, 2021 at 12:48 PM Jonathan Behrens <behrensj@...> wrote:
There are no other extensions that are proposed/drafted/in-review/ratified/ in the architecture that can implement that specific intent. (right now)
     (except ePMP which is completely backwards compatible)
Mandating the use of the only available option sounds like a no-brainer to me.

Despite the known limitations?

I don't think there's broad agreement that PMP has significant limitations. Do you have pointers to any work showing that an alternative approach would be substantially cheaper? For instance, for the server platform, I have a hard time imagining that it amounts to anything more than a rounding error in the total cost. Servers can cost thousands of dollars!

I'll try and describe the current PMP implementation requirements. Yes, and as Allen noted up thread "Note that the PMP spec is highly configurable: how many entries, its granularity, how regions can be defined, and more.
It could even be a fixed, readonly structure.", there are options up to the implementer. While the platform spec doesn't provide a reasoning for requiring PMP, it's been said multiple times in on this list that it's for protecting m-mode assets.

PMP's premise is to allow access to S/U within the system's physical address space. Quoting the spec: "In effect, PMP can grant permissions to S and U modes, which by default have none, and can revoke permissions from M-mode, which by default has full permissions."

That point necessarily requires providing a valid memory map for S/U in order for those modes to work at all if at least one PMP is implemented. Additionally, "If no PMP entry matches an S-mode or U-mode access, but at least one PMP entry is implemented, the access fails." That bit of the spec follows the intention of the first one. And "PMP violations are always trapped precisely at the processor." Makes sense, but it's also important to also think about side channel information leaks as well. Additionally, speculation has been relied upon to achieve high performant processors. One has to check against the PMPs for all load/stores in addition to instruction fetching.

The PMPs are creating a valid physical address space for U/S to operate within. There is no way, in the positive, to declare a region as M-mode only. That would be the opposite approach to PMP. The PMP construction defines what is available to U/S and anything outside of that is M-mode only despite M-mode already having full access to the physical system address space (barring punching a whole w/ a PMP entry with L=1 and no permissions granted).

PMP matching needs a priority decoder by definition of the spec to match the lowest entry. The server extension in the platform spec is requiring 16 PMP regions (quibble: should this be registers?). A priority decode after the match stage is inherently necessary for 16 PMP regions.  In addition, there are sub-page granular modes as well as the TOR mode. The latter mode requires implementing 16 adders to form a range to comparison match. The full width of each transaction needs to be checked against every entry as well because of partial match rules. The sub-page granularity is it's own complexity, but Allen correctly noted the platform is free to determine its own granularity of PMPs.

One can opt to not implement TOR, as Allen alluded to, since the A field is WARL so that would remove some of the complexity. For performance purposes, I think one would want to toss out sub-page granular modes. That would then leave naturally aligned powers of 2. And now we're left with defining the physical system address space entirely in PMP entries because PMP, by definition, only grant U/S mode access. We're paying the cost of every fetch and load/store against potentially 16 PMP entries with multiple modes and priority decoding on a per hart basis.
 
Options for implementations:
- Granularity
- A Modes
- L support
- hardwire entries (including hardwiring them to 0)

Requirements to make U/S work:
- Have to implement something to grant U/S mode physical address space access

What can standard software rely upon given the constraints above? In addition, anyone who has programmed x86 MTRRs (which have minimum 4KiB granularity) knows that it can be hard to cover the address space adequately. And, yes, I do realize those are about cacheability and not access control.

And what about the implementation restrictions/results given all those things?


Out of curiosity, do you have a system you're designing that uses a custom alternative to PMP?

Yes, we have an internal doc, and we intend to provide a proposal for a simpler way of protecting m-mode assets. We hope to get that out soon (either end of the week or early next).
 
I hope the above description provides some insight.

-Aaron




On Thu, Oct 14, 2021 at 10:16 AM Aaron Durbin <adurbin@...> wrote:


On Wed, Oct 13, 2021 at 9:08 PM Allen Baum <allen.baum@...> wrote:
Just to share my 2 <name your favorite minor currency> here: 

The RV architecture is designed to be extremely modular, and has a lot of optional behaviors
This is intended to allow implementation freedom, which is a good thing.
It is also a way that can lead to unmanageable fragmentation - and that is a bad thing. A very bad thing.
It is a tenuous balance.
So, a meta-intent - that leads to other intents - is that we want to provide services without fragmenting the architecture

Agree on the potential for unmanageable fragmentation which should definitely planned for in preventing.
 

The platform spec - in this particular case - is mandating a specific iintention (M-mode protection)  use a specific extension .

This is a quibble, but I don't see m-mode protection explicitly noted in the platform spec. I see a mandate of PMP, though.
 
There are no other extensions that are proposed/drafted/in-review/ratified/ in the architecture that can implement that specific intent. (right now)
     (except ePMP which is completely backwards compatible)
Mandating the use of the only available option sounds like a no-brainer to me.

Despite the known limitations?
 
Note that the PMP spec is highly configurable: how many entries, its granularity, how regions can be defined, and more.
It could even be a fixed, readonly structure. 

If you want to argue that server platforms don't require M-mode protection - I'm not sure you'll find a lot of agreement.
If you want to argue that server platforms should use any form of protection they like (and be declared platforn compatible - ditto.
If you want to argue that server platform fragmentation is a good thing - best of luck.

I was arguing for not requiring M-mode protection nor that fragmentation is good for the sake of fragmentation. Please point to where I made those claims so I can rectify any misinterpretation. 

What I have been and am suggesting is that PMPs have a heavy cost to particular products so we shouldn't be requiring those in the platform spec.
 

That doesn't mean that some better definition will come up, or, if it does, won't be incorporated into a revision of the platform spec.
The platform spec is an evolving document, so if you have a better way, you are free to prose it, and if it is judged better, it can be adopted.
Supporting legacy spec is always fraught, but 




On Wed, Oct 13, 2021 at 7:09 PM Atish Patra <atish.patra@...> wrote:
On Wed, 2021-10-13 at 14:15 -0600, Aaron Durbin wrote:
>
>
> On Wed, Oct 13, 2021 at 12:12 PM Atish Patra <Atish.Patra@...>
> wrote:
> > 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. 

That may lead to a lot of fragmentation in terms of implementation in
hardware and software customization. Isn't it ?

Another issue with just specifying the intent is that how do we verify
if a platform is compatible with the specification ? A custom mechanism
to protect higher privilege mode may also motivate the platform vendors
to provide vendor specific locked firmware instead of open firmware.

Having said that, platform spec can definitely relax the PMP
requirement in its future revisions for an alternative scheme that has
a lower power consumption & higher performance requirement.


> 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.
>  

Because there are no current mechanism in RISC-V specification for I/O
protection except IOPMP proposal. I am not sure what's the status of
IOPMP. That can included if the IOPMP specification becomes a reality.
 
If you think adding just the intention here would be helpful, please
suggest something along that lines or send a patch.


> >
> > 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? 

Any specification that is being drafted/frozen/ratified under RVI.
As there are lot of moving pieces as of now, platform spec refers to
other specs that are not frozen yet. But these things has to happen in
parallel to make progress.


> 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?
>   

Let me add some more clarification.

Intention: Protect m-mode run time code. (all of us agree that this
needs to happen)

Current Requirement: PMP is mandated because that is the only mechanism
provided under RV. AFAIK, all the platforms (except ariane) has
implemented PMP while agreeing that it is expensive. Power/Performance
consumption issues are known but there is no alternative.

Any other mechanism should be proposed as an ISA extension so that it
can be standardized and included in platform specification.

It is a separate discussion if we just leave at the intention and not
specify any requirement. I have given my 2 cents about that in the
above paragraph.


> >
> >
> > >  
> > > >
> > > > 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