Re: Platform Spec Technical Feedback


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

Join tech-unixplatformspec@lists.riscv.org to automatically receive all group messages.