Re: [PATCH v4 1/6] Additional requirements for H-extension
On 8/7/21 8:12 AM, Anup Patel wrote:
"Platforms are allowed to operate only in little-endian mode"
literally means that
* some platforms may be little-endian only and
* others may provide and *use* further modes
which contradicts hardwiring.
The following would make the intent clearer:
"Compliant platforms must operate in little-endian mode."
It is understandable why this specification requires little-endian mode:
e.g. we want to use UEFI which only supports little-endian systems. But
as Greg already pointed out the motivation for hardwiring to zero is
unclear and may not be future-proof.
the series consider rewording the commit message.
Best regards
Heinrich
To have a meaningful H-extension support, both OS/A-base andThe phrase
OS/A-server platforms must comply with additional requirements
for H-extension.
Signed-off-by: Anup Patel <anup.patel@...>
---
riscv-platform-spec.adoc | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index a24281f..0b30724 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -118,8 +118,22 @@ The M platform has the following extensions:
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.)
-** Platforms is allowed to operate only in little-endian mode i.e.
+** When an illegal instruction trap is taken into M-mode, exception-specific
+ information must be written to the `mtval` CSR.
+** When an illegal instruction trap is taken into S-mode, exception-specific
+ information must be written to the `stval` CSR.
+** Platforms are allowed to operate only in little-endian mode i.e.
"Platforms are allowed to operate only in little-endian mode"
literally means that
* some platforms may be little-endian only and
* others may provide and *use* further modes
which contradicts hardwiring.
The following would make the intent clearer:
"Compliant platforms must operate in little-endian mode."
It is understandable why this specification requires little-endian mode:
e.g. we want to use UEFI which only supports little-endian systems. But
as Greg already pointed out the motivation for hardwiring to zero is
unclear and may not be future-proof.
implementations must hardwire the mstatus.MBE field to 0.The requirements above are not H-extension specific. So if you respin
the series consider rewording the commit message.
Best regards
Heinrich
+** If the RISC-V ISA H-extension is implemented then the OS-A platform must
+ comply with the following additional requirements:
+*** When virtual instruction trap is taken into M-mode, exception-specific
+ information must be written to the `mtval` CSR.
+*** When virtual instruction trap is taken into S-mode, exception-specific
+ information must be written to the `stval` CSR.
+*** When guest page fault is taken into M-mode, exception-specific
+ information must be written to the `mtval2` CSR.
+*** When guest page fault is taken into S-mode, exception-specific
+ information must be written to the `htval` CSR.
[sidebar]
--
@@ -448,9 +462,13 @@ base with the additional requirements as below.
==== Architecture
The platforms which conform to server extension are required to implement +
-- RV64 support
-- RISC-V H ISA extension
-- VMID support
+* RV64 support
+* RISC-V ISA H-extension with following additional requirements:
+** VMID support
+*** When load/store/AMO fault is taken into M-mode, transformed standard
+ instruction must be written to the `mtinst` CSR.
+*** When load/store/AMO fault is taken into S-mode, transformed standard
+ instruction must be written to the `htinst` CSR.
==== PMU