Add Smstateen/Ssstateen Extension and CSRs

.pre-commit-config.yaml

@@ -119,7 +119,7 @@ repos:
     rev: v5.0.2
     hooks:
       - id: reuse-lint-file
-
+      
   - repo: https://github.com/alessandrojcm/commitlint-pre-commit-hook
     rev: v9.22.0
     hooks:

arch/csr/hstateen0.yaml

@@ -0,0 +1,144 @@
+# yaml-language-server: $schema=../../schemas/csr_schema.json
+
+$schema: "csr_schema.json#"
+kind: csr
+name: hstateen0
+long_name: Hypervisor State Enable 0 Register
+address: 0x60C
+priv_mode: S
+length: MXLEN
+description: |
+  Each bit of a `stateen` CSR controls less-privileged access to an extension’s state, for an extension that was not
+  deemed "worthy" of a full XS field in `sstatus` like the FS and VS fields for the F and V extensions.
+
+  The `stateen` registers at each level control access to state at all less-privileged levels, but not at its own level.
+  This is analogous to how the existing `counteren` CSRs control access to performance counter registers. Just as with
+  the `counteren` CSRs, when a `stateen` CSR prevents access to state by less-privileged levels, an attempt in one of those
+  privilege modes to execute an instruction that would read or write the protected state raises an illegal instruction
+  exception, or, if executing in VS or VU mode and the circumstances for a virtual instruction exception apply, raises
+  a virtual instruction exception instead of an illegal instruction exception.
+
+  When this extension is not implemented, all state added by an extension is accessible as defined by that extension.
+
+  When a `stateen` CSR prevents access to state for a privilege mode, attempting to execute in that privilege mode an
+  instruction that implicitly updates the state without reading it may or may not raise an illegal instruction or
+  virtual instruction exception. Such cases must be disambiguated by being explicitly specified one way or the other.
+
+  In some cases, the bits of the `stateen` CSRs will have a dual purpose as enables for the ISA extensions that
+  introduce the controlled state.
+
+  With the hypervisor extension, the `hstateen` CSRs have identical encodings to the `mstateen` CSRs, except controlling
+  accesses for a virtual machine (from VS and VU modes).
+
+  Each standard-defined bit of a `stateen` CSR is WARL and may be read-only zero or one, subject to the following conditions.
+
+  Bits in any `stateen` CSR that are defined to control state that a hart doesn’t implement are read-only zeros for that
+  hart. Likewise, all reserved bits not yet given a defined meaning are also read-only zeros. For every bit in an `mstateen`
+  CSR that is zero (whether read-only zero or set to zero), the same bit appears as read-only zero in the matching `hstateen`
+  and `sstateen` CSRs. For every bit in an `hstateen` CSR that is zero (whether read-only zero or set to zero), the same bit
+  appears as read-only zero in `sstateen` when accessed in VS-mode.
+
+  A bit in a supervisor-level `sstateen` CSR cannot be read-only one unless the same bit is read-only one in the matching
+  `mstateen` CSR and, if it exists, in the matching `hstateen` CSR. A bit in an `hstateen` CSR cannot be read-only one unless
+  the same bit is read-only one in the matching `mstateen` CSR.
+
+  On reset, all writable `mstateen` bits are initialized by the hardware to zeros. If machine-level software changes these
+  values, it is responsible for initializing the corresponding writable bits of the `hstateen` and `sstateen` CSRs to zeros
+  too. Software at each privilege level should set its respective `stateen` CSRs to indicate the state it is prepared to
+  allow less-privileged software to access. For OSes and hypervisors, this usually means the state that the OS or hypervisor
+  is prepared to swap on a context switch, or to manage in some other way.
+
+  For each `mstateen` CSR, bit 63 is defined to control access to the matching `sstateen` and `hstateen` CSRs. That is, bit 63
+  of `mstateen0` controls access to `sstateen0` and `hstateen0`; bit 63 of `mstateen1` controls access to `sstateen1` and `hstateen1`;
+  etc. Likewise, bit 63 of each `hstateen` correspondingly controls access to the matching `sstateen` CSR.
+
+  A hypervisor may need this control over accesses to the `sstateen` CSRs if it ever must emulate for a virtual machine
+  an extension that is supposed to be affected by a bit in an `sstateen` CSR. Even if such emulation is uncommon, it should not be excluded.
+
+  Machine-level software needs identical control to be able to emulate the hypervisor extension. That is, machine level needs control over
+  accesses to the supervisor-level `sstateen` CSRs in order to emulate the `hstateen` CSRs, which have such control.
+
+definedBy:
+  allOf:
+    - H
+    - Smstateen
+    - Ssstateen
+fields:
+  SE0:
+    location: 63
+    base: 64
+    description: |
+      The SE0 bit in `hstateen0` controls access to the `sstateen0` CSR.
+    type: RW
+    reset_value: UNDEFINED_LEGAL
+  ENVCFG:
+    location: 62
+    base: 64
+    description: |
+      The ENVCFG bit in `hstateen0` controls access to the `senvcfg` CSRs.
+    type: RW
+    reset_value: UNDEFINED_LEGAL
+  CSRIND:
+    location: 60
+    base: 64
+    description: |
+      The CSRIND bit in `hstateen0` controls access to the `siselect` and the
+      `sireg*`, (really `vsiselect` and `vsireg*`) CSRs provided by the Sscsrind
+      extensions.
+    type: RW
+    reset_value: UNDEFINED_LEGAL
+  AIA:
+    location: 59
+    base: 64
+    description: |
+      The AIA bit in `hstateen0` controls access to all state introduced by
+      the Ssaia extension and is not controlled by either the CSRIND or the
+      IMSIC bits of `hstateen0`.
+    type: RW
+    reset_value: UNDEFINED_LEGAL
+  IMSIC:
+    location: 58
+    base: 64
+    description: |
+      The IMSIC bit in `hstateen0` controls access to the guest IMSIC state,
+      including CSRs `stopei` (really `vstopei`), provided by the Ssaia extension.
+
+      Setting the IMSIC bit in `hstateen0` to zero prevents a virtual machine
+      from accessing the hart’s IMSIC the same as setting `hstatus.`VGEIN = 0.
+    type: RW
+    reset_value: UNDEFINED_LEGAL
+  CONTEXT:
+    location: 57
+    base: 64
+    description: |
+      The CONTEXT bit in `hstateen0` controls access to the `scontext` CSR provided
+      by the Sdtrig extension.
+    type: RW
+    reset_value: UNDEFINED_LEGAL
+  JVT:
+    location: 2
+    description: |
+      The JVT bit controls access to the `jvt` CSR provided by the Zcmt extension.
+    type: RW
+    reset_value: UNDEFINED_LEGAL
+  FCSR:
+    location: 1
+    description: |
+      The FCSR bit controls access to `fcsr` for the case when floating-point instructions
+      operate on `x` registers instead of `f` registers as specified by the Zfinx and related
+      extensions (Zdinx, etc.). Whenever `misa.F` = 1, FCSR bit of `mstateen0` is read-only
+      zero (and hence read-only zero in `hstateen0` and `sstateen0` too). For convenience,
+      when the `stateen` CSRs are implemented and `misa.F` = 0, then if the FCSR bit of a
+      controlling `stateen0` CSR is zero, all floating-point instructions cause an illegal
+      instruction trap (or virtual instruction trap, if relevant), as though they all access
+      `fcsr`, regardless of whether they really do.
+    type: RW
+    reset_value: UNDEFINED_LEGAL
+  C:
+    location: 0
+    description: |
+      The C bit controls access to any and all custom state. This bit is not custom state itself.
+      The C bit of these registers is not custom state itself; it is a standard field of a
+      standard CSR, either `mstateen0`, `hstateen0`, or `sstateen0`.
+    type: RW
+    reset_value: UNDEFINED_LEGAL

arch/csr/hstateen0h.yaml

@@ -0,0 +1,71 @@
+# yaml-language-server: $schema=../../schemas/csr_schema.json
+
+$schema: "csr_schema.json#"
+kind: csr
+name: hstateen0h
+long_name: Upper 32 bits of Hypervisor State Enable 0 Register
+address: 0x61C
+priv_mode: S
+length: 32
+base: 32
+description: |
+  For RV64 harts, the Smstateen/Ssstateen extension adds four new 64-bit CSRs at machine level: `mstateen0` (Machine State Enable 0),
+  `mstateen1`, `mstateen2`, and `mstateen3`. If supervisor mode is implemented, another four CSRs are defined at
+  supervisor level: `sstateen0`, `sstateen1`, `sstateen2`, and `sstateen3`. And if the hypervisor extension is implemented,
+  another set of CSRs is added: `hstateen0`, `hstateen1`, `hstateen2`, and `hstateen3`.
+
+  For RV32, the registers listed above are 32-bit, and for the machine-level and hypervisor CSRs there is a corresponding
+  set of high-half CSRs for the upper 32 bits of each register: `mstateen0h`, `mstateen1h`, `mstateen2h`, `mstateen3h`, `hstateen0h`,
+  `hstateen1h`, `hstateen2h`, and `hstateen3h`.
+
+definedBy:
+  allOf:
+    - H
+    - Smstateen
+    - Ssstateen
+fields:
+  SE0:
+    location: 31
+    description: |
+      The SE0 bit in `hstateen0h` controls access to the `sstateen0` CSR.
+    type: RW
+    reset_value: UNDEFINED_LEGAL
+  ENVCFG:
+    location: 30
+    description: |
+      The ENVCFG bit in `hstateen0h` controls access to the `senvcfg` CSRs.
+    type: RW
+    reset_value: UNDEFINED_LEGAL
+  CSRIND:
+    location: 28
+    description: |
+      The CSRIND bit in `hstateen0h` controls access to the `siselect` and the
+      `sireg*`, (really `vsiselect` and `vsireg*`) CSRs provided by the Sscsrind
+      extensions.
+    type: RW
+    reset_value: UNDEFINED_LEGAL
+  AIA:
+    location: 27
+    description: |
+      The AIA bit in `hstateen0h` controls access to all state introduced by
+      the Ssaia extension and is not controlled by either the CSRIND or the
+      IMSIC bits of `hstateen0`.
+    type: RW
+    reset_value: UNDEFINED_LEGAL
+  IMSIC:
+    location: 26
+    description: |
+      The IMSIC bit in `hstateen0h` controls access to the guest IMSIC state,
+      including CSRs `stopei` (really `vstopei`), provided by the Ssaia extension.
+
+      Setting the IMSIC bit in `hstateen0h` to zero prevents a virtual machine
+      from accessing the hart’s IMSIC the same as setting `hstatus.`VGEIN = 0.
+    type: RW
+    reset_value: UNDEFINED_LEGAL
+  CONTEXT:
+    location: 25
+    description: |
+      The CONTEXT bit in `hstateen0h` controls access to the `scontext` CSR provided
+      by the Sdtrig extension.
+    type: RW
+    reset_value: UNDEFINED_LEGAL

arch/csr/hstateen1.yaml

@@ -0,0 +1,73 @@
+# yaml-language-server: $schema=../../schemas/csr_schema.json
+
+$schema: "csr_schema.json#"
+kind: csr
+name: hstateen1
+long_name: Hypervisor State Enable 1 Register
+address: 0x60D
+priv_mode: S
+length: MXLEN
+description: |
+  Each bit of a `stateen` CSR controls less-privileged access to an extension’s state, for an extension that was not
+  deemed "worthy" of a full XS field in `sstatus` like the FS and VS fields for the F and V extensions.
+
+  The `stateen` registers at each level control access to state at all less-privileged levels, but not at its own level.
+  This is analogous to how the existing `counteren` CSRs control access to performance counter registers. Just as with
+  the `counteren` CSRs, when a `stateen` CSR prevents access to state by less-privileged levels, an attempt in one of those
+  privilege modes to execute an instruction that would read or write the protected state raises an illegal instruction
+  exception, or, if executing in VS or VU mode and the circumstances for a virtual instruction exception apply, raises
+  a virtual instruction exception instead of an illegal instruction exception.
+
+  When this extension is not implemented, all state added by an extension is accessible as defined by that extension.
+
+  When a `stateen` CSR prevents access to state for a privilege mode, attempting to execute in that privilege mode an
+  instruction that implicitly updates the state without reading it may or may not raise an illegal instruction or
+  virtual instruction exception. Such cases must be disambiguated by being explicitly specified one way or the other.
+
+  In some cases, the bits of the `stateen` CSRs will have a dual purpose as enables for the ISA extensions that
+  introduce the controlled state.
+
+  With the hypervisor extension, the `hstateen` CSRs have identical encodings to the `mstateen` CSRs, except controlling
+  accesses for a virtual machine (from VS and VU modes).
+
+  Each standard-defined bit of a `stateen` CSR is WARL and may be read-only zero or one, subject to the following conditions.
+
+  Bits in any `stateen` CSR that are defined to control state that a hart doesn’t implement are read-only zeros for that
+  hart. Likewise, all reserved bits not yet given a defined meaning are also read-only zeros. For every bit in an `mstateen`
+  CSR that is zero (whether read-only zero or set to zero), the same bit appears as read-only zero in the matching `hstateen`
+  and `sstateen` CSRs. For every bit in an `hstateen` CSR that is zero (whether read-only zero or set to zero), the same bit
+  appears as read-only zero in `sstateen` when accessed in VS-mode.
+
+  A bit in a supervisor-level `sstateen` CSR cannot be read-only one unless the same bit is read-only one in the matching
+  `mstateen` CSR and, if it exists, in the matching `hstateen` CSR. A bit in an `hstateen` CSR cannot be read-only one unless
+  the same bit is read-only one in the matching `mstateen` CSR.
+
+  On reset, all writable `mstateen` bits are initialized by the hardware to zeros. If machine-level software changes these
+  values, it is responsible for initializing the corresponding writable bits of the `hstateen` and `sstateen` CSRs to zeros
+  too. Software at each privilege level should set its respective `stateen` CSRs to indicate the state it is prepared to
+  allow less-privileged software to access. For OSes and hypervisors, this usually means the state that the OS or hypervisor
+  is prepared to swap on a context switch, or to manage in some other way.
+
+  For each `mstateen` CSR, bit 63 is defined to control access to the matching `sstateen` and `hstateen` CSRs. That is, bit 63
+  of `mstateen0` controls access to `sstateen0` and `hstateen0`; bit 63 of `mstateen1` controls access to `sstateen1` and `hstateen1`;
+  etc. Likewise, bit 63 of each `hstateen` correspondingly controls access to the matching `sstateen` CSR.
+
+  A hypervisor may need this control over accesses to the `sstateen` CSRs if it ever must emulate for a virtual machine
+  an extension that is supposed to be affected by a bit in an `sstateen` CSR. Even if such emulation is uncommon, it should not be excluded.
+
+  Machine-level software needs identical control to be able to emulate the hypervisor extension. That is, machine level needs control over
+  accesses to the supervisor-level `sstateen` CSRs in order to emulate the `hstateen` CSRs, which have such control.
+
+definedBy:
+  allOf:
+    - H
+    - Smstateen
+    - Ssstateen
+fields:
+  SE0:
+    location: 63
+    base: 64
+    description: |
+      The SE0 bit in `hstateen1` controls access to the `sstateen1` CSR.
+    type: RW
+    reset_value: UNDEFINED_LEGAL

arch/csr/hstateen1h.yaml

@@ -0,0 +1,32 @@
+# yaml-language-server: $schema=../../schemas/csr_schema.json
+
+$schema: "csr_schema.json#"
+kind: csr
+name: hstateen1h
+long_name: Upper 32 bits of Hypervisor State Enable 1 Register
+address: 0x61D
+priv_mode: S
+length: 32
+base: 32
+description: |
+  For RV64 harts, the Smstateen/Ssstateen extension adds four new 64-bit CSRs at machine level: `mstateen0` (Machine State Enable 0),
+  `mstateen1`, `mstateen2`, and `mstateen3`. If supervisor mode is implemented, another four CSRs are defined at
+  supervisor level: `sstateen0`, `sstateen1`, `sstateen2`, and `sstateen3`. And if the hypervisor extension is implemented,
+  another set of CSRs is added: `hstateen0`, `hstateen1`, `hstateen2`, and `hstateen3`.
+
+  For RV32, the registers listed above are 32-bit, and for the machine-level and hypervisor CSRs there is a corresponding
+  set of high-half CSRs for the upper 32 bits of each register: `mstateen0h`, `mstateen1h`, `mstateen2h`, `mstateen3h`, `hstateen0h`,
+  `hstateen1h`, `hstateen2h`, and `hstateen3h`.
+
+definedBy:
+  allOf:
+    - H
+    - Smstateen
+    - Ssstateen
+fields:
+  SE0:
+    location: 31
+    description: |
+      The SE0 bit in `hstateen1h` controls access to the `sstateen1` CSR.
+    type: RW
+    reset_value: UNDEFINED_LEGAL