Jonathan Behrens <behrensj@...>
If writing non-zero values to mtval and stval are going to be required by OS/A-base, then I think it should require non-zero values for mtinst and htinst. The transformed instruction encodings for mtinst and htinst were specifically designed to be easier for implementations to provide than the original instruction bits. The specification text could be something like:
"On any exception, if version XYZ of the priv spec allows a non-zero Transformed Standard Instruction to be written to mtinst/htinst (as indicated by Table 5.9 and the list of transformed instructions), then the implementation must always write a non-zero value to mtinst/htinst".
Can the *tinst wording correspond more directly to priv Table 5.9. Is the intent the following, or something more relaxed?
- "Yes" in the "Transformed Standard Instruction" means that that content must be written to *tinst for that exception - "No" in the
"Transformed Standard Instruction" means that zero must be written to *tinst for that exception
-Josh
Hi Jonathan,
Current approach is to mandate mtinst and htinst only for OS-A Server. If more people agree then we can mandate mtinst and htinst for OS-A Base.
Regards,
Anup
The H-extension adds a mtinst and htinst registers. If we're requiring non-zero values in mtval and stval, shouldn't those have similar requirements?
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
>
>
|
