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