[PATCH v4 1/6] Additional requirements for H-extension
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
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
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
>
>
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
>
>
To have a meaningful H-extension support, both OS/A-base andReviewed-by: Alistair Francis <alistair.francis@...>
OS/A-server platforms must comply with additional requirements
for H-extension.
Signed-off-by: Anup Patel <anup.patel@...>
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
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 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
>
>
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
>
>
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-JoshOn 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
>
>
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
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
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
>
>