On 07/08/21, 12:56 PM, "Heinrich Schuchardt" <xypron.glpk@...> wrote:



On 8/7/21 8:12 AM, Anup Patel wrote:
> To have a meaningful H-extension support, both OS/A-base and
> 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.

The phrase
"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.

Sure, let me update the text here and also the commit message.

Regards,
Anup

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