[PATCH v4 1/6] Additional requirements for H-extension


Anup Patel
 

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


Heinrich Schuchardt
 

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.

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


Anup Patel
 

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?


On Sat, Aug 7, 2021 at 5:48 AM Anup Patel via lists.riscv.org <anup.patel=wdc.com@...> wrote:


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







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 and
OS/A-server platforms must comply with additional requirements
for H-extension.

Signed-off-by: Anup Patel <anup.patel@...>
Reviewed-by: Alistair Francis <alistair.francis@...>

Alistair

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


Anup Patel
 

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@...>
Date: Saturday, 7 August 2021 at 8:04 PM
To: Anup Patel <Anup.Patel@...>
Cc: Heinrich Schuchardt <xypron.glpk@...>, Kumar Sankaran <ksankaran@...>, Atish Patra <Atish.Patra@...>, Greg Favor <gfavor@...>, "tech-unixplatformspec@..." <tech-unixplatformspec@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v4 1/6] Additional requirements for H-extension

 

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:



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






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:

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@...>
Date: Saturday, 7 August 2021 at 8:04 PM
To: Anup Patel <Anup.Patel@...>
Cc: Heinrich Schuchardt <xypron.glpk@...>, Kumar Sankaran <ksankaran@...>, Atish Patra <Atish.Patra@...>, Greg Favor <gfavor@...>, "tech-unixplatformspec@..." <tech-unixplatformspec@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v4 1/6] Additional requirements for H-extension

 

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:



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

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

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@...>
Date: Saturday, 7 August 2021 at 8:04 PM
To: Anup Patel <Anup.Patel@...>
Cc: Heinrich Schuchardt <xypron.glpk@...>, Kumar Sankaran <ksankaran@...>, Atish Patra <Atish.Patra@...>, Greg Favor <gfavor@...>, "tech-unixplatformspec@..." <tech-unixplatformspec@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v4 1/6] Additional requirements for H-extension

 

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:



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






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

Reviewed-by: Atish Patra <atish.patra@...>

--
Regards,
Atish


Anup Patel
 

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@...>
Date: Monday, 9 August 2021 at 9:31 PM
To: Anup Patel <Anup.Patel@...>
Cc: Jonathan Behrens <behrensj@...>, Heinrich Schuchardt <xypron.glpk@...>, Kumar Sankaran <ksankaran@...>, Atish Patra <Atish.Patra@...>, Greg Favor <gfavor@...>, "tech-unixplatformspec@..." <tech-unixplatformspec@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v4 1/6] Additional requirements for H-extension

 

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:

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@...>
Date: Saturday, 7 August 2021 at 8:04 PM
To: Anup Patel <Anup.Patel@...>
Cc: Heinrich Schuchardt <xypron.glpk@...>, Kumar Sankaran <ksankaran@...>, Atish Patra <Atish.Patra@...>, Greg Favor <gfavor@...>, "tech-unixplatformspec@..." <tech-unixplatformspec@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v4 1/6] Additional requirements for H-extension

 

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:



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