Re: Platform Spec Technical Feedback


atishp@...
 

On Wed, 2021-10-13 at 09:20 -0600, Aaron Durbin wrote:


On Tue, Oct 12, 2021 at 9:51 PM Greg Favor <gfavor@...>
wrote:
On Tue, Oct 12, 2021 at 2:23 PM Aaron Durbin <adurbin@...>
wrote:
1. Zam required, but as far as I can see there is no plan for
ratification in the current items on the docket for ratification.

Both Zam and Ztso are not yet ratified standards - which is going
to start to be rectified soon.

What's the plan for soon? And what is the definition of soon? It's
not in the list of things to be standardized this Fall. It would be
good to have visibility on these fronts.

 
1. ACLINT - why is this required? This is forcing an
implementation to use that when it's not necessarily needed.

Keep in mind that it is not as simple as saying that "ACLINT is
required".  The OS-A Base spec provides four options for what a
system implements as far as interrupt control.

The 2.1.4.1. Timer support section states "One or more ACLINT MTIMER
devices are required for the OS-A platform"

Is the MTIMER device inclusive of the MTIME register and the set of
MTIMECMP register sets? And what is the thinking here along with Sstc
extension?

I'm looking for more clarity in the spec that constitutes 'ACLINT
MTIMER devices'. Perhaps we should link to a particular section such
as 
https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc#2-machine-level-timer-device-mtimer
It might even be worth separating the MTIMER device from the ACLINT
spec itself since the requirement above is standalone.
ACLINT is a modular spec. It allows flexibility in implementing all
three (MSWI/SSWI/MTIMER) devices. That's why, a platform can implement
only MTIMER.

In fact, server extension mandates only the last option where only
MTIMER is mandatory. Both M-mode/S-mode software interrupts must be
managed by IMSIC.

The interrupt & timer table clearly lays out these options. We can add
some text to "2.1.4.2.4. MSIs, Virtual MSIs, and Wired IRQs" if
required as well.

 



In RISC-V there have been two de facto standards (PLIC and CLINT)
that were never properly established as official RV standards but
are used by many people - which is in the process of being
addressed.  ACLINT is part of the effort to standardize the
existing CLINT, provide more flexibility to CLINT implementations,
and to add on the SSWI part that mirrors the existing MSWI part
(for systems that don't want or need to implement AIA).

Thank you for the history.
 
 
2. APLIC - Same question as ACLINT? Relatedly, why are wired IRQs
called out as being necessary and supported by way of an APLIC?
Why can't wired IRQs be supported in another way?

The Base platform supports use of PLIC, ACLINT, and AIA (and its
IMSIC and APLIC parts).  It is not requiring that all OS-A Base
compliant systems implement APLIC (or any part of AIA).

But there is no option to not implement an APLIC or PLIC, correct?
Why not? IMSIC on its own is certainly valid. 
Yes. Platform spec just providing all the options. Wired irqs can only
be generated using APLIC or PLIC while MSIs through IMSIC.
That's why, platform spec provides that guidance.

If a Platform only wants rely on MSIs for everything, it is okay to
implement just IMSIC. That's why, server extension only mandates

2.1.4.2.4. MSIs, Virtual MSIs, and Wired IRQs

which states

"One, or more AIA APLIC devices are required to support wired
interrupts."

APLIC can be ignored in case there are no wired irq interrupts in the
system.

We can certainly improve the text if it is not clear.

 

For supporting wired interrupts one has two choices - PLIC and
APLIC.  (And within RISC-V there will also be CLIC for more
embedded-oriented designs.)

Why just those two? And are these wired interrupts internal to a part
or external? Why couldn't one implement a different way to generate
IRQs from an external wire? That is definitely dictating product
implementation.

And where does this 'wired IRQ' requirement come from exactly?
There's seems to be some implied assumptions, but they are not clear
what that section is trying to address.
 
 
3. PMPs - I believe this is an M-mode intention to protect m-mode
assets. Why is an implementation being mandated instead of
requesting M-mode asset protection from the harts? Moreover,
there doesn't appear to be a requirement that protects M-mode
assets from I/O agents.

Note that the current RV architecture (other than things like AIA,
Debug, and E-Trace) is "CPU" architecture.  Things like IOPMP and
IOMMU will address the needs around I/O agents in a system
(including equivalents to CPU PMAs and PMPs).

So the spec doesn't address m-mode asset protection fully, but it
decided to focus on "cpu" and force an implementation? I understand
the distinction between hart and !hart, but I don't see the point of
requiring PMP specifically. What should be in the spec is the
intention: provide a mechanism to protect m-mode assets from hart
access as well as I/O agents.

-Aaron
 
--
Regards,
Atish

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