Date
1 - 6 of 6
[PATCH 1/2] Remove the machine mode requirements
|
atishp@...
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 |
|
|
|
Ved Shanbhogue
Looks good to me. I notice that a few other sections have interspersed
toggle quoted message
Show quoted text
M-mode requirements that could be similarly addressed. A few additional related comments inline. 1. Table 1 - columns with requirements on M-mode 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.." 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? - "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. - "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". - "Configure PMP CSRs" - could be removed to match the other updates - "SBI TIME" - Since Server extension (section 2.2.1.1) mandates Sstc, the SBI TIME should be optional and not required. 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. 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 |
|
|
|
Darius Rad
On Sun, Oct 31, 2021 at 12:51:26AM -0700, Atish Patra wrote:
As per the discussion in the mailing list, M-mode requirementsI disagree that the specification provides standardization of U and VU modes. At best it provides a small and incomplete set of requirements for those modes.
|
|
|
|
atishp@...
On Sun, 2021-10-31 at 14:56 -0500, Vedvyas Shanbhogue wrote:
Looks good to me. I notice that a few other sections haveTable 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. 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. 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 andThis is required for base only. - "Emulate missing CSRs" - Quite ambigous as to which CSRNot 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 otherYes. 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) mandatesAs 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. 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, Atish |
|
|
|
Ved Shanbhogue
On Thu, Nov 04, 2021 at 02:51:23PM +0000, Atish Patra wrote:
On Sun, 2021-10-31 at 14:56 -0500, Vedvyas Shanbhogue wrote:Agree that adding a clarification that these are "required" only if supporting SW interrupts or other interrupts to M-mode is supported. Else the specification reads as if these are always required.Same explanation as above. MSWI devices are required only if M-mode Could that be clarified. Presently there is only one section for runtime services and it does not make a distinction between base and server.- "Handle misaligned load and store" - should this be optional andThis is required for base only. This was added to make sure that supervisor mode software can continueI dont think the architecture implements CMO CSRs. Perhaps these are custom CSRs? I feel the requirements could be stated differently. We could list all CSRs that supervisor mode software requires to be present. Then a platform may choose to emulate them or implement them in hardware. Otherwise this requirement to emulate missing CSRs is puzzling because as a silicon designer or a M-mode firmware designer one is left wondering what emulations should be implemented. Agree. That would address the above as well. SBI interface is mandatory. Thus, the M-mode runtime must at leastAgree. This list of SBI extensions for server extension will change along withThanks. That makes sense. That sounds good to me.Sure. May be we can include the PCIe snippet in the general note as regards ved |
|
|
|
atishp@...
On Thu, 2021-11-04 at 10:21 -0500, Ved Shanbhogue wrote:
On Thu, Nov 04, 2021 at 02:51:23PM +0000, Atish Patra wrote:Sure. I will update the patch.On Sun, 2021-10-31 at 14:56 -0500, Vedvyas Shanbhogue wrote:Agree that adding a clarification that these are "required" only ifSame explanation as above. MSWI devices are required only if M-mode I was talking about the CMO (cache management operations) CSRs.Could that be clarified. Presently there is only one section for- "Handle misaligned load and store" - should this be optionalThis is required for base only. Here are the details. https://github.com/riscv/riscv-CMOs/blob/master/specifications/cmobase-v0.6.pdf ok. I am going to remove the M-mode runtime requirement section. All of them are implicit anyways. --SBI interface is mandatory. Thus, the M-mode runtime must at leastAgree. Regards, Atish |
|
|