[PATCH v4 1/6] Additional requirements for H-extension
|
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. implementations must hardwire the mstatus.MBE field to 0. +** 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 -- 2.25.1 |
|
|
|
On 8/7/21 8:12 AM, Anup Patel wrote:
To have a meaningful H-extension support, both OS/A-base andThe 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. Best regards Heinrich +** If the RISC-V ISA H-extension is implemented then the OS-A platform must |
|
|
|
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 > > |
|
|
|
Jonathan Behrens <behrensj@...>
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?
|
|
|
|
Alistair Francis <alistair.francis@...>
On Sat, 2021-08-07 at 11:42 +0530, Anup Patel wrote:
To have a meaningful H-extension support, both OS/A-base andReviewed-by: Alistair Francis <alistair.francis@...> Alistair --- |
|
|
|
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
From: Jonathan Behrens <behrensj@...>
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 Sat, Aug 7, 2021 at 5:48 AM Anup Patel via
lists.riscv.org <anup.patel=wdc.com@...> wrote:
|
|
|
|
Josh Scheid
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 On Mon, Aug 9, 2021 at 7:35 AM Anup Patel <anup.patel@...> wrote:
|
|
|
|
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". On Mon, Aug 9, 2021 at 12:01 PM Josh Scheid via lists.riscv.org <jscheid=ventanamicro.com@...> wrote:
|
|
|
|
atishp@...
On Sat, 2021-08-07 at 11:42 +0530, Anup Patel wrote:
To have a meaningful H-extension support, both OS/A-base and Reviewed-by: Atish Patra <atish.patra@...> -- Regards, Atish |
|
|
|
I think we should move the requirement to OS-A base and clearly state that non-zero exception specific information should be written to mtinst or htinst.
Regards, Anup
From: <tech-unixplatformspec@...> on behalf of Josh Scheid <jscheid@...>
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
On Mon, Aug 9, 2021 at 7:35 AM Anup Patel <anup.patel@...> wrote:
|
|
|