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
>-values).
>-* 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.

Best regards

Heinrich


>+
>+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