Merge pull request #1 from dhower/main

Many updates: (#8)

.github/workflows/regress.yml

@@ -12,12 +12,14 @@ jobs:
       uses: actions/checkout@v4
     - name: Setup apptainer
       uses: eWaterCycle/[email protected]
+    - name: Read container tag
+      run: echo "CONTAINER_TAG=$(cat bin/.container-tag)" >> $GITHUB_ENV
     - name: Get container from cache
       id: cache-sif
       uses: actions/cache@v3
       with:
-        path: .singularity/image.sif
-        key: ${{ hashFiles('container.def') }}
+        path: .singularity/image${{ env.CONTAINER_TAG }}.sif
+        key: ${{ hashFiles('container.def', 'bin/.container-tag') }}
     - name: Get gems and node files from cache
       id: cache-bundle-npm
       uses: actions/cache@v3

README.adoc

@@ -38,7 +38,7 @@ This repository contains:
 
 == Prerequisites
 
-The only requirement is the `Singularity CE` or `Apptainer` container system. Either one will work (they are forks).
+The only requirement is the `Singularity CE` (>= 3.3) or `Apptainer` (>= 1.0) container system. Either one will work (they are forks).
 
 If it is not installed, either as your IT admin or:
 

arch/csr/menvcfg.yaml

@@ -158,6 +158,30 @@ menvcfg:
       definedBy: Svpbmt
       type: RW
       reset_value: UNDEFINED_LEGAL
+    ADUE:
+      location: 61
+      description: |
+        If the Svadu extension is implemented, the ADUE bit controls whether hardware updating of
+        PTE A/D bits is enabled for S-mode and G-stage address translations. When ADUE=1, hardware
+        updating of PTE A/D bits is enabled during S-mode address translation, and the
+        implementation behaves as though the Svade extension were not implemented for S-mode address
+        translation.
+        
+        When the hypervisor extension is implemented, if ADUE=1, hardware updating of PTE A/D bits
+        is enabled during G-stage address translation, and the implementation behaves as though the
+        Svade extension were not implemented for G-stage address translation. When ADUE=0, the
+        implementation behaves as though Svade were implemented for S-mode and
+        G-stage address translation.
+
+        If Svadu is not implemented, ADUE is read-only zero.
+
+        Furthermore, for implementations with the hypervisor extension, henvcfg.ADUE is read-only
+        zero if menvcfg.ADUE is zero.
+      definedBy: Svadu
+      type(): |
+        return (implemented?(ExtensionName::Svadu)) ? CsrFieldType::RO : CsrFieldType::RW;
+      reset_value(): |
+        return (implemented?(ExtensionName::Svadu)) ? UNDEFINED_LEGAL : 0;
     CBZE:
       location: 7
       description: |

arch/csr/menvcfgh.yaml

@@ -28,3 +28,13 @@ menvcfgh:
       definedBy: Svpbmt
       type: RW
       reset_value: UNDEFINED_LEGAL
+    ADUE:
+      location: 29
+      alias: menvcfg.ADUE
+      description: |
+        Alias of `menvcfg.ADUE`
+      definedBy: Svadu
+      type(): |
+        return (implemented?(ExtensionName::Svadu)) ? CsrFieldType::RO : CsrFieldType::RW;
+      reset_value(): |
+        return (implemented?(ExtensionName::Svadu)) ? UNDEFINED_LEGAL : 0;

arch/csr/mepc.yaml

@@ -37,7 +37,7 @@ mepc:
       reset_value: 0
   sw_read(): |
     if (implemented?(ExtensionName::C) && CSR[misa].C == 1'b1) {
-      return CSR[mepc] & ~64'b1;
+      return CSR[mepc].PC & ~64'b1;
     } else {
-      return CSR[mepc];
+      return CSR[mepc].PC;
     }

arch/ext/A.yaml

@@ -3,13 +3,26 @@
 A:
   type: unprivileged
   long_name: Atomic instructions
+  company:
+    name: RISC-V International
+    url: https://riscv.org
   versions:
   - version: 2.1
     state: ratified
     ratification_date: 2019-12
+    contributors:
+    - name: Unknown
+      email: [email protected]
+      company: Unknown
     implies:
     - [Zaamo, 1.0]
     - [Zalrsc, 1.0]
+    required_parameters:
+    - MUTABLE_MISA_A
+    - LRSC_RESERVATION_STRATEGY
+    - LRSC_FAIL_ON_VA_SYNONYM
+    - LRSC_FAIL_ON_NON_EXACT_LRSC
+    - LRSC_MISALIGNED_BEHAVIOR
   description: |
 
     The atomic-instruction extension, named `A`, contains

arch/ext/Svade.yaml

@@ -0,0 +1,40 @@
+# yaml-language-server: $schema=../../schemas/ext_schema.json
+
+Svade:
+  long_name: Exception on PTE A/D Bits
+  type: unprivileged
+  description: |
+    The Svade extension indicates that hardware does *not* update the A/D bits of a page table
+    during a page walk. Rather, encountering a PTE with the A bit clear or the D bit clear when
+    an operation is a write will cause a Page Fault.
+  versions:
+  - version: 1.0
+    state: ratified
+    ratification_date: 2023-11
+    url: https://github.com/riscvarchive/riscv-svadu/releases/download/v1.0/riscv-svadu.pdf
+    repositories:
+    - url: https://github.com/riscvarchive/riscv-svadu
+      branch: main
+    contributors:
+    - name: Aaron Durbin
+      company: Rivos, Inc.
+    - name: Andrew Waterman
+      company: SiFive
+    - name: Earl Killian
+      company: Aril
+    - name: Greg Favor
+      company: Ventana
+    - name: John Ingalls
+      company: SiFive
+    - name: Ken Dockser
+      company: Tenstorrent
+    - name: Krste Asanovic
+      company: SiFive
+    - name: Paul Donahue
+    - name: Ved Shanbhogue
+      company: Rivos, Inc.
+    conflicts: Svadu
+  doc_license:
+    name: Creative Commons Attribution 4.0 International License (CC-BY 4.0)
+    url: https://creativecommons.org/licenses/by/4.0/
+

arch/ext/Svadu.yaml

@@ -0,0 +1,123 @@
+# yaml-language-server: $schema=../../schemas/ext_schema.json
+
+Svadu:
+  long_name: Hardware Updating of PTE A/D Bits
+  type: unprivileged
+  description: |
+    The Svadu extension adds support and CSR controls for hardware updating of PTE
+    A/D bits. The A and D bits are managed by these extensions as follows:
+
+    * When a virtual page is accessed and the A bit is clear, the PTE is updated to
+      set the A bit.  When the virtual page is written and the D bit is clear, the
+      PTE is updated to set the D bit. When G-stage address translation is in use
+      and is not Bare, the G-stage virtual pages may be accessed or written by 
+      implicit accesses to VS-level memory management data structures, such as page
+      tables.
+
+    * When two-stage address translation is in use, an explicit access may cause
+      both VS-stage and G-stage PTEs to be updated. The following rules apply to all
+      PTE updates caused by an explicit or an implicit memory accesses.            +
+                                                                                  +
+      The PTE update must be atomic with respect to other accesses to the PTE, and
+      must atomically perform all tablewalk checks for that leaf PTE as part of, and
+      before, conditionally updating the PTE value. Updates of the A bit may be
+      performed as a result of speculation, even if the associated memory access
+      ultimately is not performed architecturally. However, updates to the D bit,
+      resulting from an explicit store, must be exact (i.e., non-speculative), and
+      observed in program order by the local hart. When two-stage address
+      translation is active, updates of the D bit in G-stage PTEs may be performed
+      as a result of speculative updates of the A bit in VS-stage PTEs.            +
+                                                                                  +
+      The PTE update must appear in the global memory order before the memory access
+      that caused the PTE update and before any subsequent explicit memory access to
+      that virtual page by the local hart. The ordering on loads and stores provided
+      by FENCE instructions and the acquire/release bits on atomic instructions also
+      orders the PTE updates associated with those loads and stores as observed by
+      remote harts.                                                                +
+                                                                                  +
+      The PTE update is not required to be atomic with respect to the memory access
+      that caused the update and a trap may occur between the PTE update and the 
+      memory access that caused the PTE update. If a trap occurs then the A and/or D
+      bit may be updated but the memory access that caused the PTE update might not
+      occur. The hart must not perform the memory access that caused the PTE update
+      before the PTE update is globally visible.
+
+    [NOTE]
+    ====
+    The PTE updates due to memory accesses ordered-after a FENCE are not themselves
+    ordered by the FENCE.
+
+    Simpler implementations that cannot precisely order the PTE update before
+    subsequent explicit memory accesses to the associated virtual page by the local
+    hart may simply order the PTE update before all subsequent explicit memory
+    accesses to any virtual page by the local hart.
+    ====
+
+    Svadu extension requires the page tables to be located in memory with hardware
+    page-table write access and _RsrvEventual_ PMA.
+
+    <<<
+
+    The translation of virtual addresses (or guest physical addresses) to physical
+    (or guest physical) addresses is accomplished with the same algorithm as
+    specified in the Supervisor-Level ISA extension (section "Virtual Address
+    Translation Process") and as modified by the hypervisor extension (section
+    "Two-stage Address Translation"), except that step 7 of the translation process,
+    instead of causing a page-fault exception due to A and/or D bits being 0 when
+    required to be 1, continues as follows:
+
+    [start=7]
+    . If `pte.a = 0`, or if the original memory access is a store and `pte.d = 0`:
+    .. If a store to `pte` would violate a PMA or PMP check, raise an access-fault
+      exception corresponding to the original access type.
+    .. Perform the following steps atomically:
+    ... Compare `pte` to the value of the PTE at address `a + va.vpn[i] * PTESIZE`.
+    ... If the values match, set `pte.a` to 1 and, if the original memory access is
+        a store, also set `pte.d` to 1.
+    ... If the comparison fails, return to step 2
+
+    The Svadu extension adds the `ADUE` bit (bit 61) to `menvcfg`. When
+    `menvcfg.ADUE` is 1, hardware updating of PTE A/D bits is enabled during
+    single-stage address translation. When the hypervisor extension is implemented,
+    if `menvcfg.ADUE` is 1, hardware updating of PTE A/D bits is enabled during
+    G-stage address translation.  When `menvcfg.ADUE` is zero, the implementation
+    behaves as though Svadu were not implemented. If Svadu is not implemented,
+    `menvcfg.ADUE` is read-only zero. Furthermore, for implementations with the
+    hypervisor extension, `henvcfg.ADUE` is read-only zero if `menvcfg.ADUE` is zero.
+
+    When the hypervisor extension is implemented, the Svadu extension adds the
+    `ADUE` bit (bit 61) to `henvcfg`. When `henvcfg.ADUE` is 1, hardware updating of
+    PTE A/D bits is enabled during VS-stage address translation. When `henvcfg.ADUE`
+    is zero, the implementation behaves as though Svadu were not implemented for
+    VS-stage address translation.
+  versions:
+  - version: 1.0
+    state: ratified
+    ratification_date: 2023-11
+    url: https://github.com/riscvarchive/riscv-svadu/releases/download/v1.0/riscv-svadu.pdf
+    repositories:
+    - url: https://github.com/riscvarchive/riscv-svadu
+      branch: main
+    contributors:
+    - name: Aaron Durbin
+      company: Rivos, Inc.
+    - name: Andrew Waterman
+      company: SiFive
+    - name: Earl Killian
+      company: Aril
+    - name: Greg Favor
+      company: Ventana
+    - name: John Ingalls
+      company: SiFive
+    - name: Ken Dockser
+      company: Tenstorrent
+    - name: Krste Asanovic
+      company: SiFive
+    - name: Paul Donahue
+    - name: Ved Shanbhogue
+      company: Rivos, Inc.
+    conflicts: Svade
+  doc_license:
+    name: Creative Commons Attribution 4.0 International License (CC-BY 4.0)
+    url: https://creativecommons.org/licenses/by/4.0/
+

arch/inst/A/lr.d.yaml

@@ -0,0 +1,87 @@
+# yaml-language-server: $schema=../../../schemas/inst_schema.json
+
+lr.d:
+  long_name: Load reserved doubleword
+  description: |
+     Loads a word from the address in rs1, places the value in rd,
+     and registers a _reservation set_  -- a set of bytes that subsumes the bytes in the
+     addressed word.
+
+     The address in rs1 must be 8-byte aligned.
+
+     If the address is not naturally aligned, a `LoadAddressMisaligned` exception or an
+     `LoadAccessFault` exception will be generated. The access-fault exception can be generated
+     for a memory access that would otherwise be able to complete except for the misalignment,
+     if the misaligned access should not be emulated.
+
+     An implementation can register an arbitrarily large reservation set on each LR, provided the
+     reservation set includes all bytes of the addressed data word or doubleword.
+     An SC can only pair with the most recent LR in program order.
+     An SC may succeed only if no store from another hart to the reservation set can be
+     observed to have occurred between the LR and the SC, and if there is no other SC between the
+     LR and itself in program order.
+     An SC may succeed only if no write from a device other than a hart to the bytes accessed by
+     the LR instruction can be observed to have occurred between the LR and SC. Note this LR
+     might have had a different effective address and data size, but reserved the SC's
+     address as part of the reservation set.
+
+     [NOTE]
+     ----
+     Following this model, in systems with memory translation, an SC is allowed to succeed if the
+     earlier LR reserved the same location using an alias with a different virtual address, but is
+     also allowed to fail if the virtual address is different.
+
+     To accommodate legacy devices and buses, writes from devices other than RISC-V harts are only
+     required to invalidate reservations when they overlap the bytes accessed by the LR.
+     These writes are not required to invalidate the reservation when they access other bytes in
+     the reservation set.
+     ----
+
+     Software should not set the _rl_ bit on an LR instruction unless the _aq_ bit is also set.
+     LR.rl and SC.aq instructions are not guaranteed to provide any stronger ordering than those
+     with both bits clear, but may result in lower performance.
+  definedBy: [A, Zalrsc]
+  base: 64
+  assembly: xd, xs1
+  encoding:
+    match: 00010--00000-----011-----0101111
+    variables:
+    - name: aq
+      location: 26
+    - name: rl
+      location: 27
+    - name: rs1
+      location: 19-15
+    - name: rd
+      location: 11-7
+  access:
+    s: always
+    u: always
+    vs: always
+    vu: always
+  operation(): |
+    if (implemented?(ExtensionName::A) && (CSR[misa].A == 1'b0)) {
+      raise (ExceptionCode::IllegalInstruction, $encoding);
+    }
+
+    XReg virtual_address = X[rs1];
+
+    if (!is_naturally_aligned<XLEN, 64>(virtual_address)) {
+      # can raise either LoadAddressMisaligned *or* LoadAccessFault
+      #
+      # from the spec:
+      #   If the address is not naturally aligned, an address-misaligned exception or
+      #   an access-fault exception will be generated. The access-fault exception can
+      #   be generated for a memory access that would otherwise be able to complete except
+      #   for the misalignment, if the misaligned access should not be emulated.
+
+      if (LRSC_MISALIGNED_BEHAVIOR == "always raise misaligned exception") {
+        raise(ExceptionCode::LoadAddressMisaligned, virtual_address);
+      } else if (LRSC_MISALIGNED_BEHAVIOR == "always raise access fault") {
+        raise(ExceptionCode::LoadAccessFault, virtual_address);
+      } else {
+        unpredictable("Implementations may raise either a LoadAddressMisaligned or a LoadAccessFault when an LR/SC address is misaligned");
+      }
+    }
+
+    X[rd] = load_reserved<32>(virtual_address, aq, rl);

arch/inst/A/lr.w.yaml

@@ -70,5 +70,27 @@ lr.w:
 
     XReg virtual_address = X[rs1];
 
-    #X[rd] = load_reserved<32>(virtual_address);
-    X[rd] = read_memory<32>(virtual_address);
+    if (!is_naturally_aligned<XLEN, 32>(virtual_address)) {
+      # can raise either LoadAddressMisaligned *or* LoadAccessFault
+      #
+      # from the spec:
+      #   If the address is not naturally aligned, an address-misaligned exception or
+      #   an access-fault exception will be generated. The access-fault exception can
+      #   be generated for a memory access that would otherwise be able to complete except
+      #   for the misalignment, if the misaligned access should not be emulated.
+
+      if (LRSC_MISALIGNED_BEHAVIOR == "always raise misaligned exception") {
+        raise(ExceptionCode::LoadAddressMisaligned, virtual_address);
+      } else if (LRSC_MISALIGNED_BEHAVIOR == "always raise access fault") {
+        raise(ExceptionCode::LoadAccessFault, virtual_address);
+      } else {
+        unpredictable("Implementations may raise either a LoadAddressMisaligned or a LoadAccessFault when an LR/SC address is misaligned");
+      }
+    }
+
+    XReg load_value = load_reserved<32>(virtual_address, aq, rl);
+    if (xlen() == 64) {
+      X[rd] = load_value;
+    } else {
+      X[rd] = sext(load_value[31:0], 32);
+    }