Re: [PATCH 6/6] Update the ISA requirement section


On Fri, Nov 19, 2021 at 12:01 AM Heinrich Schuchardt <xypron.glpk@...> wrote:
Am 19. November 2021 01:09:34 MEZ schrieb atishp@...:
>Some of the ISA requirement sections do not belong to a platform
>specification and can move to the profile specification. The fence.i
>recommendation belong to software section as it talks about a requirement
>for userspace applications. While at it, provide a better clarification
>for the above requirement as well. Thanks Andrew & Greg for reviewing
>this section.
>Update the ISA requirement section to reflect that.
>Suggested-by: Greg Favor <gfavor@...>
>Signed-off-by: Atish Patra <atishp@...>
> riscv-platform-spec.adoc | 38 +++++++++++++-------------------------
> 1 file changed, 13 insertions(+), 25 deletions(-)
>diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
>index 81ae740154c1..3e901bb4c5e0 100644
>--- a/riscv-platform-spec.adoc
>+++ b/riscv-platform-spec.adoc
>@@ -108,43 +108,22 @@ Supervisor level (S-mode/VS-mode) and M-mode/HS-mode respectively.
> // Base feature set for OS-A Platform
> === Base
> ==== ISA Requirements
>-===== ISA Profile Requirements
>-* The OS-A platform must comply with the following profiles defined by the
>-RISC-V profiles specification <<spec_profiles>>.
>-** RVA22U profile for user-mode.
>-** RVA22S profile for supervisor-mode.
>-*** The I, M, A, C extensions must be supported.
> ===== General
>+* This OS-A platform must comply with the RVA22U and RVA22S ISA profiles as
>+defined in the RISC-V ISA Profiles specification [11].
> * A non-conforming extension that conflicts with a supported standard extensions
> must satisfy at least one of the following:
> ** It must be disabled by default.
> ** The supported standard extension must be declared as unsupported in all
> feature discovery structures used by software. This option is allowed only
> if the standard extension is not required.
>-* The LR/SC reservation set size must be at least 16B and at most 128B.
>-* Cacheable main memory regions must support instruction fetch, AMOArithmetic,
>-RsrvEventual, and PTE reads and writes.
>-* All unimplemented or disabled opcodes and CSRs must raise an
>-Illegal Instruction exception.
>-* Within main-memory regions, aligned instruction fetch must be atomic, up to
>-the smaller of ILEN and XLEN bits. In particular, if an aligned 4-byte word
>-is stored with the `sw` instruction, then any processor attempts to execute
>-that word, the processor either fetches the newly stored word, or some previous
>-value stored to that location.  (That is, the fetched instruction is not an
>-unpredictable value, nor is it a hybrid of the bytes of the old and new
>-* All harts must adhere to the RVWMO memory model.
> * All hart PMA regions for main memory must be marked as coherent.
> * Memory accesses by I/O masters can be coherent or non-coherent with respect
> to all hart-related caches.
> [sidebar]
>-[underline]*_Recommendation_* +
>-User-mode programs should not execute the `fence.i` instruction.
> ===== Supervisor mode
> * sstatus
> ** sstatus.UBE must support the same access attribute (read-only or writable)
>@@ -540,6 +519,15 @@ software components:
> Rationale: The platform specification intends to avoid fragmentation and
> promotes interoperability.
>+* To order older stores before younger instruction fetches, user-level programs must
>+use system-supplied library calls (e.g. GNU libc's `__riscv_flush_icache`, which
>+invokes the Linux kernel's corresponding vDSO routine), rather than executing
>+the `fence.i` instruction directly.

It seems irrelevant if a library call is made or the syscall is invoked directly.

A libc library may be used by some programs but will be unused by others.

The important thing is that the kernel is used for ordering.

Agreed. However, the additional verbose explanation doesn't hurt.
So I am inclined to keep it unless somebody is strongly opposed to it.
Best regards


>+Rationale: The `fence.i` instruction only orders the current hart's instruction
>+fetches - which is insufficient even for single-threaded programs since a thread
>+may migrate to a different hart.
> === Security
> ** If M-mode is supported in the platform, all machine mode assets, such as
> code and data, shall be protected from all non-machine mode accesses from the

Join { to automatically receive all group messages.