Re: [PATCH 1/2] Remove the machine mode requirements


atishp@...
 

On Sun, 2021-10-31 at 14:56 -0500, Vedvyas Shanbhogue wrote:
Looks good to me. I notice that a few other sections have
interspersed
M-mode requirements that could be similarly addressed. A few
additional
related comments inline.

1. Table 1 - columns with requirements on M-mode
Table 1 merely states the information rather than requirement.
For example:
If category 3 (MSIs and Wired IRQs) is used, MSIs at M-mode can
be provided using IMSIC while wired interrupts at M-mode can be
provided using APLIC.


2. Section 2.1.4.2.3  and 2.1.4.2.4 - requirements on M-mode
   "Per-hart AIA IMSIC device to support MSIs for M-mode"
   "Software interrupts for M-mode,..."

3. Section 2.1.4.2.1 and secttion 2.1.4.2.2 - requirements on M-mode
   "One or more ACLINT MSWI devices are required to support M-mode.."
Same explanation as above. MSWI devices are required only if M-mode
interrupt is required.

We probably can add more clarification around this text to avoid the
confusion so that there are some guidance on MMIO devices for systems
with M-mode.


4. Section 2.1.7.1 - M-mode runtime requirements
   - "Delegate interrupts and exceptions to S-mode." Does this
contradict
     a bit with later sections on firmware-first RAS support where
some
     interrupts may be handled first by M-mode?
Not really as the text in RAS says "generate an interrupt request to
the system interrupt controller that may be directed to either M-mode
or S/HS-mode for firmware-first or OS-first error reporting."

If firmware-first approach is chosen, M-mode should handle the
interrupts.

   - "Handle misaligned load and store" - should this be optional and
     not required. The server extension (section 2.2.1.1) recommends
     hardware support for mislaligned accesses.
This is required for base only.

   - "Emulate missing CSRs" - Quite ambigous as to which CSR
     should be considered missing (and when) and when/why they should
be
     emulated). This also contradicts with statement in section
2.1.1.2 "All
     unimplemented or disabled opcodes and CSRs must raise an illegal
     instruction exception".
Not really. The latter text is an requirement for hardware where it
should raise illegal instruction exception while the former content
says that the M-mode runtime software should emulate the missing CSRs
by handling the illegal instruction exception.

This was added to make sure that supervisor mode software can continue
to work for the platforms that did not implements certain CSRs in
hardware. Some of the CSRs that can I think of

1. TIME
2. CMOs (to support Alwinner D1 & beagleV)
3. HTIMEDELTA (if H extension is present)

   - "Configure PMP CSRs" - could be removed to match the other
updates
Yes. I will update the patch.

On a second thought, we can remove the entire "Required features of the
M-Mode runtime also include:" section as M-mode is no longer mandatory.

SBI interface is mandatory. Thus, the M-mode runtime must at least
implement SBI v0.3 with specific extensions.

This list of SBI extensions for server extension will change along with
major changes of removing the extension concept and renaming the base
spec to OS-A embedded.

For the server extension, only the following SBI extension will be
mandatory.

PMU, HSM, SRST


   - "SBI TIME" - Since Server extension (section 2.2.1.1) mandates
     Sstc, the SBI TIME should be optional and not required.
As discussed in the last meeting, we are moving away extension model
for server. Thus, SBI TIME is only mandatory for Base (or OS-A Embedded
spec as per the latest meeting) not server.

 
5. Section 2.2.7.3.2
   The note and the associated implementation note about providing a
   mechanism controlled by M-mode software could be removed since now
   there is a more general note in the security section added by
patch 2
   of this set about protecting M-mode assets from I/O agents.
Sure. May be we can include the PCIe snippet in the general note as
well.

Additionally, I am thinking moving the implementation note to the new
security section would provide more clarity about the requirement while
allowing alternate implementation. Any thoughts ?



regards
ved


On Sun, Oct 31, 2021 at 12:51:26AM -0700, Atish Patra wrote:
As per the discussion in the mailing list, M-mode requirements
should not be included in this version of the platform
specification
to allow platform vendors more flexibility in implementing
privilege
modes. Moreover, platform specification doesn't guarantee inter-
operability
between M-mode software/firmwares. Thus, specifying M-mode
requirements
adds restriction while not providing any significant value.

Remove the machine mode requirements for this version of the
platform
specification.

Signed-off-by: Atish Patra <atish.patra@...>
---
 riscv-platform-spec.adoc | 52 ++++--------------------------------
----
 1 file changed, 4 insertions(+), 48 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index b2388dbaf834..bf92acb32329 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -37,7 +37,6 @@ toc::[]
 |OSPM      | Operating System Power Management
 |RVA22U64  | RISC-V 2022 user-mode profile <<spec_profiles>>
 |RVA22S64  | RISC-V 2022 supervisor-mode profile <<spec_profiles>>
-|RVA22M64  | RISC-V 2022 machine-mode profile <<spec_profiles>>
 |RAS       | Reliability, Availability, and Serviceability
 |CLINT     | Legacy Core-Local Interrupt Controller
 |ACLINT    | Advanced Core-Local Interrupt Controller
<<spec_aclint>>
@@ -98,6 +97,10 @@ feature set and extensions as shown below: +
 ** *Base*
 ** *Physical Memory Protection (PMP) Extension*
 
+The current version of this platform spec targets the
standardization of
+functionality available in S, U, VS and VU modes, and the
standardization of
+the SBI (Supervisory Binary Interface as defined in <<spec_sbi>>)
between
+Supervisor level (S-mode/VS-mode) and M-mode/HS-mode respectively.
 
 // OS-A Platform
 == OS-A Platform
@@ -111,7 +114,6 @@ feature set and extensions as shown below: +
 RISC-V profiles specification <<spec_profiles>>.
 ** RVA22U profile for user-mode.
 ** RVA22S profile for supervisor-mode.
-** RVM20M64 profile for machine-mode.
 *** The I, M, A, C extensions must be supported.
 
 ===== General
@@ -143,48 +145,6 @@ to all hart-related caches.
 User-mode programs should not execute the `fence.i` instruction.
 
 --
-===== Machine Mode
-* mvendorid, marchid, mimpid and mhartid registers must be
supported and not
-hardwired to 0.
-
-* mstatus
-** TVM bit must not be hardwired to 0.
-** TW bit must not be hardwired to 0.
-** TSR bit must not be hardwired to 0.
-** MBE, SBE and UBE must each be either hardwired to 0 or writable
and
-initialized by reset or boot firmware for LE operation.
-
-* mtvec
-** Both direct and vectored modes must be supported.
-** The alignment constraint for BASE fields must be at most 256B.
-
-* medeleg
-** All bits for defined and supported exceptions except
'Environment call
-from M-mode' must be writable.
-
-* mideleg
-** Bits for MSI, MTI and MEI must be hardwired to 0.
-
-* mcounteren
-** Writeable bits must be implemented for all supported (not
hardwired to zero)
-hpmcounters.
-
-* mcountinhibit
-** Writeable bits must be implemented for all supported (not
hardwired to zero)
-hpmcounters.
-
-* mtval
-** mtval must not be hardwired to 0 and in all cases must be
written with
-non-zero and zero values as architecturally defined.
-
-* mtval2
-**  If H extension is supported then mtval2 must not be hardwired
to 0 and in
-all cases must be written with non-zero and zero values as
architecturally
-defined.
-
-* PMP
-** Minimum of 4 PMP regions must be supported.
-
 ===== Supervisor mode
 * sstatus
 ** sstatus.UBE must support the same access attribute (read-only
or writable)
@@ -603,10 +563,6 @@ satisfying a requirement.
 There should be hardware support for all misaligned accesses;
misaligned
 accesses should not take address misaligned exceptions.
 
-===== Machine Mode
-* PMP/ePMP
-** Minimum of 16 PMP regions must be supported.
-
 ===== Supervisor mode
 * satp
 ** For RV64, Sv48 translation mode must be supported.
--
2.31.1








--
Regards,
Atish

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