On Wed, 2021-10-13 at 09:54 -0600, Aaron Durbin wrote:
On Wed, Oct 13, 2021 at 9:50 AM Jonathan Behrens <behrensj@...>
wrote:
3. PMPs - I believe this is an M-mode intention to protect m-
mode assets. Why is an implementation being mandated instead of
requesting M-mode asset protection from the harts? Moreover,
there
doesn't appear to be a requirement that protects M-mode assets
from
I/O agents.
Note that the current RV architecture (other than things like
AIA, Debug, and E-Trace) is "CPU" architecture. Things like
IOPMP
and IOMMU will address the needs around I/O agents in a system
(including equivalents to CPU PMAs and PMPs).
So the spec doesn't address m-mode asset protection fully, but it
decided to focus on "cpu" and force an implementation? I
understand the distinction between hart and !hart, but I don't
see the point of requiring PMP specifically. What should be in
the spec is the intention: provide a mechanism to protect m-mode
assets from hart access as well as I/O agents.
The spec requires PMP so that standard M-mode software like OpenSBI
can assume that PMP is implemented. If the requirement was "PMP or
any other asset protection implementation" then OpenSBI would need
to have special handling for every different possible
implementation. I'd also point out that PMP isn't just for
defending against malicious code, it also protects against buggy
code accidentally corrupting M-mode memory.
OpenSBI implementation already has platform specific code in it. PMP,
as specified, is not conducive to all designs. It has power and
performance implications that can be onerous depending on what one is
optimizing for. Is the platform spec trying to protect the OpenSBI
software project?
Obviously not. PMP is the only standard method for protecting M-mode
runtime code specified by ISA. That's why, it is mandated in platform
spec and OpenSBI uses it.
If the RISC-V allows any other standard mechanism in future, OpenSBI
will support it. E.g. There were some discussion supporting ePMP in
OpenSBI. However, there are no usecase for that as of now. That's why
it is not implemented yet.
Same is applicable for platform spec. Similar to interrupt controller
options, the platform spec is open to have multiple options to protect
M-mode implementation. It's just that we don't any other standard
option defined by the spec.
Jonathan
On Wed, Oct 13, 2021 at 11:21 AM Aaron Durbin via lists.riscv.org <
adurbin=rivosinc.com@...> wrote:
On Tue, Oct 12, 2021 at 9:51 PM Greg Favor <
gfavor@...> wrote:
On Tue, Oct 12, 2021 at 2:23 PM Aaron Durbin <
adurbin@...> wrote:
1. Zam required, but as far as I can see there is no plan for
ratification in the current items on the docket for
ratification.
Both Zam and Ztso are not yet ratified standards - which is
going to start to be rectified soon.
What's the plan for soon? And what is the definition of soon?
It's not in the list of things to be standardized this Fall. It
would be good to have visibility on these fronts.
1. ACLINT - why is this required? This is forcing an
implementation to use that when it's not necessarily needed.
Keep in mind that it is not as simple as saying that "ACLINT is
required". The OS-A Base spec provides four options for what a
system implements as far as interrupt control.
The 2.1.4.1. Timer support section states "One or more ACLINT
MTIMER devices are required for the OS-A platform"
Is the MTIMER device inclusive of the MTIME register and the set
of MTIMECMP register sets? And what is the thinking here along
with Sstc extension?
I'm looking for more clarity in the spec that constitutes 'ACLINT
MTIMER devices'. Perhaps we should link to a particular section
such as
https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc#2-machine-level-timer-device-mtimer
It might even be worth separating the MTIMER device from the
ACLINT spec itself since the requirement above is standalone.
In RISC-V there have been two de facto standards (PLIC and
CLINT) that were never properly established as official RV
standards but are used by many people - which is in the process
of being addressed. ACLINT is part of the effort to
standardize the existing CLINT, provide more flexibility to
CLINT implementations, and to add on the SSWI part that mirrors
the existing MSWI part (for systems that don't want or need to
implement AIA).
Thank you for the history.
2. APLIC - Same question as ACLINT? Relatedly, why are wired
IRQs called out as being necessary and supported by way of an
APLIC? Why can't wired IRQs be supported in another way?
The Base platform supports use of PLIC, ACLINT, and AIA (and
its IMSIC and APLIC parts). It is not requiring that all OS-A
Base compliant systems implement APLIC (or any part of AIA).
But there is no option to not implement an APLIC or PLIC,
correct? Why not? IMSIC on its own is certainly valid.
For supporting wired interrupts one has two choices - PLIC and
APLIC. (And within RISC-V there will also be CLIC for more
embedded-oriented designs.)
Why just those two? And are these wired interrupts internal to a
part or external? Why couldn't one implement a different way to
generate IRQs from an external wire? That is definitely dictating
product implementation.
And where does this 'wired IRQ' requirement come from exactly?
There's seems to be some implied assumptions, but they are not
clear what that section is trying to address.
3. PMPs - I believe this is an M-mode intention to protect m-
mode assets. Why is an implementation being mandated instead
of requesting M-mode asset protection from the harts?
Moreover, there doesn't appear to be a requirement that
protects M-mode assets from I/O agents.
Note that the current RV architecture (other than things like
AIA, Debug, and E-Trace) is "CPU" architecture. Things like
IOPMP and IOMMU will address the needs around I/O agents in a
system (including equivalents to CPU PMAs and PMPs).
So the spec doesn't address m-mode asset protection fully, but it
decided to focus on "cpu" and force an implementation? I
understand the distinction between hart and !hart, but I don't
see the point of requiring PMP specifically. What should be in
the spec is the intention: provide a mechanism to protect m-mode
assets from hart access as well as I/O agents.
-Aaron
--
Regards,
Atish
