`satp` write with an unsupported MODE still updates ASID and PPN (Priv 1.10 requires the entire write to have no effect)

[dreamqin68]

Summary

On main at b91c909, a csrw satp whose MODE field the core does not support correctly leaves MODE unchanged, but still writes the new ASID and PPN. The Privileged Architecture version this core declares requires the write to have no effect at all.

The result is that satp lands in a state no single legal write could produce — the old MODE beside a new PPN — and the address translation root is silently replaced while software is being told the write was rejected.

What is measured below is the satp readback, which is the architectural interface the specification sentence is about. That the walk then proceeds from the new root is argued from the source and not observed: the walker's root-PPN port is not architecturally visible, so a full-core run cannot show it. Both halves are set out under What the RTL does.

The rule

RISC-V Privileged Architecture 1.10, src/supervisor.tex:

Implementations are not required to support all MODE settings, and if satp is written with an unsupported MODE, the entire write has no effect; no fields in satp are modified.

The C910 manual §1.5 declares Privileged Architecture 1.10 and names exactly one post-1.10 adoption (mcountinhibit), so this rule is in the declared target. The sentence is also byte-identical in ratified 1.11 and 1.12, and it entered the manual more than four years before this core's first public commit, so there is no contemporaneous version in which it is absent or weaker:

riscv-isa-manual 26f0d7a5567a8c1a1b9faa9ce4d9a70e05b2f7a6   // added 2017-04-11

What the RTL does

C910_RTL_FACTORY/gen_rtl/mmu/rtl/ct_mmu_regs.v. Two write blocks with different guards:

:634   else if(satp_write_en && cp0_mmu_wdata[62:60] == 3'b0)   // MODE: guarded correctly
:635     satp_mode[3:0]            <= {cp0_mmu_wdata[63],3'b0};

:645   else if(satp_write_en)                                    // ASID and PPN: no MODE condition
:647     satp_asid[ASID_WIDTH-1:0] <= cp0_mmu_wdata[59:44];
:648     satp_ppn[PPN_WIDTH-1:0]   <= cp0_mmu_wdata[PPN_WIDTH-1:0];

The MODE guard admits only wdata[62:60] == 3'b0, i.e. Bare and Sv39. That is correct for an Sv39-only core — this is a narrow finding about the second block, not a claim that satp is broken.

Two lines out of a priority chain cannot show that those guards are the only conditions under which the fields are written, so here are both blocks in full, and the readback, from ct_mmu_regs.v:

The complete always blocks and the readback

:630 always @(posedge mmu_regs_clk or negedge cpurst_b)
:631 begin
:632   if(!cpurst_b)
:633     satp_mode[3:0]            <= {4{1'b0}};
:634   else if(satp_write_en && cp0_mmu_wdata[62:60] == 3'b0)
:635     satp_mode[3:0]            <= {cp0_mmu_wdata[63],3'b0};
:636 end
:638 always @(posedge mmu_regs_clk or negedge cpurst_b)
:639 begin
:640   if(!cpurst_b)
:641   begin
:642     satp_asid[ASID_WIDTH-1:0] <= {ASID_WIDTH{1'b0}};
:643     satp_ppn[PPN_WIDTH-1:0]   <= {PPN_WIDTH{1'b0}};
:644   end
:645   else if(satp_write_en)
:646   begin
:647     satp_asid[ASID_WIDTH-1:0] <= cp0_mmu_wdata[59:44];
:648     satp_ppn[PPN_WIDTH-1:0]   <= cp0_mmu_wdata[PPN_WIDTH-1:0];
:649   end
:650 end
:652 assign satp_data[63:0] = {satp_mode[3:0],satp_asid[ASID_WIDTH-1:0],
:653                           16'b0,satp_ppn[PPN_WIDTH-1:0]};

Every line from :630 to :653 is quoted above; the only two omitted are the blank lines :637 and :651. That matters, because an excerpt cannot establish what the next sentence claims: two arms each, reset and write, and nothing else. There is no third arm to mask either one, no other write path to satp_asid or satp_ppn, and the readback assembles all three fields with satp_ppn among them — which is why the table below is a measurement of the architectural register, and why the one-line change is sufficient rather than merely necessary.

The write enable both guards share is one line in the same file, and it carries no field condition of its own:

:284 assign satp_write_en  =  cp0_mmu_satp_sel;

The name is sel and not wen, and it is driven from another module, so two things are worth closing rather than assuming: that a csrr satp does not assert it, and that the signal reaching ct_mmu_regs.v is the one ct_cp0_regs.v drives. Neither holds by name. Both are below, and the read question closes on a conjunction: satp_write_en is cp0_mmu_satp_sel, which is iui_regs_sel && satp_local_en, which needs inst_csr_ex2, which is only ever loaded with inst_csr_ex1 && !iui_inst_ro. Every step is an AND, so iui_inst_ro alone forces satp_write_en low, whatever the other terms do — and iui_inst_ro is exactly the architectural no-write set, CSRRS and CSRRC and their immediate forms with a zero source, which is what csrr assembles to.

The read/write chain and the module-to-module connection, quoted

In ct_cp0_regs.v, the address decode carries no read-or-write information, so the whole question is iui_regs_sel:

:1433 assign satp_local_en     = iui_regs_addr[11:0] == SATP;
:4246 assign cp0_mmu_satp_sel     = iui_regs_sel && satp_local_en;

iui_regs_sel is produced in ct_cp0_iui.v. iui_uimm is the instruction's rs1 field, so the one zero-source test covers the register forms and the immediate forms alike:

:797 assign iui_uimm[63:0]   = {59'b0, iui_ex1_opcode[19:15]};
:801 assign iui_inst_ro      = (iui_inst_csrrs  || iui_inst_csrrc
:802                         || iui_inst_csrrsi || iui_inst_csrrci)
:803                         && iui_uimm[4:0] == 5'b0;
:1415 always @ (posedge cpuclk or negedge cpurst_b)
:1416 begin
:1417   if(!cpurst_b)
:1418     inst_csr_ex2 <= 1'b0;
:1419   else if(cp0_ex1_select)
:1420     inst_csr_ex2 <= (inst_csr_ex1 && !iui_inst_ro);
:1421   else
:1422     inst_csr_ex2 <= 1'b0;
:1423 end
:1425 assign iui_regs_sel          = inst_csr_ex2 && cp0_ex2_select;

The block is quoted whole because the conjunction depends on it: only ever loaded with is an exhaustiveness claim, and one arm that set inst_csr_ex2 unconditionally would break the chain. The other two arms both clear it.

cp0_ex2_select is left as a conjunct here, unexpanded. It resolves in the same file to iui_ex2_commit, which is RTU's commit of this instruction, so opening it would answer a different question — whether a write can happen on a flushed instruction. A conjunct is enough to show that a read cannot write, and one that is not needed to answer the question is not opened, so no line of it is quoted here.

The name cp0_mmu_satp_sel occurs in six files, and a shared name is not a shared net. The port connections are, from the driver in ct_cp0_regs.v:

:402 output           cp0_mmu_satp_sel;

up through ct_cp0_top.v, on its x_ct_cp0_regs instance:

:930   .cp0_mmu_satp_sel                (cp0_mmu_satp_sel               ),

and ct_core.v, on its x_ct_cp0_top instance:

:4625   .cp0_mmu_satp_sel                (cp0_mmu_satp_sel               ),

The two subtrees meet in ct_top.v, at the x_ct_core instance and the x_ct_mmu_top instance:

:917   .cp0_mmu_satp_sel                     (cp0_mmu_satp_sel                    ),
:1331   .cp0_mmu_satp_sel         (cp0_mmu_satp_sel        ),

then down through ct_mmu_top.v, on its x_ct_mmu_regs instance:

:700   .cp0_mmu_satp_sel         (cp0_mmu_satp_sel        ),

to the input in ct_mmu_regs.v that :284 consumes:

:76 input           cp0_mmu_satp_sel;

Case A in the reproduction comment is consistent with the read half and does not establish it: csrr is CSRRS with a zero source, so a read that erroneously wrote would write back the value already there, and no readback separates that from no write at all. The conjunction above, and not the run, is what carries it.

Two more facts about the same file support the table below rather than the finding itself: the readback is decodable field by field, and every satp write flushes the micro-TLB, including the rejected ones — so stale translations do not survive to mask the seam.

Decoding the readback, and the micro-TLB flush

The readback in ct_mmu_regs.v is decodable, so the table below can be checked rather than believed. :230 and :233 give the widths — PPN_WIDTH = 40-12 and ASID_WIDTH = 16 — so :652 reads {MODE[3:0], ASID[15:0], 16'b0, PPN[27:0]}. Take the setup value 0x801110000000aaaa: MODE 0x8 (Sv39), ASID 0x0111, bits 43:28 zero, PPN 0xaaaa. That is the setup written field for field.

:230 parameter PPN_WIDTH  = 40-12;  // PPN
:233 parameter ASID_WIDTH = 16;     // Flags

One thing that decoding makes visible and is not part of this report: satp_ppn is 28 bits, so a write's bits 43:28 are dropped and read back as the 16'b0 field. That is the architecture's own PPN width for Sv39 on a 40-bit physical address, not a second partial update.

The same file also flushes the micro-TLB on every satp write, including the rejected ones:

:238 assign regs_utlb_clr = satp_write_en;

So the old translations do not survive to mask the seam: the walker is forced to re-walk from the root PPN that was just installed.

Reproduction

A full reproduction — tool version strings, the exact commands, every test program and the whole of each run's output, each with a sha256 — is posted as the first comment on this issue.

Every transcript excerpt in this report is reformatted for reading — 0x added, short annotations appended, cases grouped by what they demonstrate rather than kept in the order the program prints them, and lines the paragraph is not about left out. The reproduction comment carries each run's output verbatim and in full, so a line here can always be found there.

Whole SoC from reset, under the vendor's own smart_run Verilator flow with logical/tb/tb_verilator.v unmodified, rv64imafdc, Verilator 5.048. The test is ordinary M-mode csrw / csrr.

openc910 at b91c90914c19f114d35c8f6b73408eb241ed847c

Each case re-runs its own setup write and then its probe write, so the two columns of every transcript line are that case's own satp after setup and after probe. Six of the seven use the Sv39 setup 0x801110000000aaaa (ASID 0x111, PPN 0xaaaa); case F sets up from Bare instead, which is why its rows differ in the MODE nibble.

That matters for the last column. "Required by 1.10" is not an independent assertion: the rule is that no field is modified, so the required value IS the same row's setup readback, which the run measured.

case	satp after setup, observed	probe write	satp after probe, observed	required by 1.10
C	0x801110000000aaaa	0x902220000000bbbb (MODE=9, Sv48)	0x802220000000bbbb	0x801110000000aaaa
D	0x801110000000aaaa	0x103330000000cccc (MODE=1)	0x803330000000cccc	0x801110000000aaaa
E	0x801110000000aaaa	0xa04440000000dddd (MODE=10, Sv57)	0x804440000000dddd	0x801110000000aaaa
F	0x001110000000aaaa	0x905550000000eeee (MODE=9, from Bare)	0x005550000000eeee	0x001110000000aaaa

Controls in the same run, which behave correctly — each is a legal write, and each lands in full:

case	satp after setup, observed	probe write	satp after probe, observed
B	0x801110000000aaaa	0x802220000000bbbb (MODE=8, supported)	0x802220000000bbbb
G	0x801110000000aaaa	0x006660000000ffff (MODE=0, Bare)	0x006660000000ffff

The reproduction comment carries a seventh case. A makes no probe write at all and reports the setup value twice; it is the bring-up control that says the harness is driving the CSR write path before any of the six above is read as evidence.

No trap is taken in any case, and that part is correct: satp.MODE is WARL, and the specification requires an unsupported MODE to be ignored, not refused. It is worth stating only because it is what leaves software with nothing to notice — the write instruction completes, the MODE readback is unchanged, and there is no signal of any kind that the other two fields moved.

Why routine CSR testing does not find this

The correct behaviour depends on the register's current value, because "no fields are modified" means the old ASID and PPN must survive. A single-write check that writes an unsupported MODE and inspects the MODE readback passes: MODE really is rejected. Single-write WARL sweeps, random CSR generators and CSR-access suites structurally cannot construct the precondition.

Whether this is isolated

Within the scope swept, the neighbours of this line are right: this is one line and not a general pattern in the file.

What was swept, what was conformant, and the bound

We swept every CSR field written from the write-data bus in ct_cp0_regs.v, plus the satp path, looking for this specific shape: legalization that depends on the register's current contents and not on the written value alone. Six neighbours were checked and are conformant, including the two nearest misreads — mtvec.MODE and stvec.MODE, where the store is raw but the readback and the vector the fetch unit receives both drop the illegal bit, so readback and behaviour agree; and the mideleg-dependent masking of sie and sip, which is this same current-value shape on the register where it matters most.

We are not claiming that sweep was exhaustive, and it is worth being exact about why: it asked one question, and a field that diverges for some other reason would not answer it. The bound matters as much as the result: readback paths, trap-entry side effects and the custom C910 extension CSRs were not covered, and the sweep is a source-level reading — nothing in it was elaborated or simulated. What it does support is the narrow statement a maintainer needs to prioritise this: within that scope, the neighbours of this line are right, so what follows is one line and not a general pattern in the file.

Practical scenario

Supervisor software probes for Sv48 the conventional way a WARL field's supported values are discovered — and the way the same sentence implies, since it is the rejected write's lack of effect that makes the probe safe: write satp with MODE=9 and the Sv48 root, read back, see whether MODE stuck. Per the specification, nothing changed. On this core the software reads MODE=8, correctly concludes Sv48 is unsupported — and has no indication that its address-space root was replaced by the Sv48 root it just probed with, with the micro-TLB flushed so the walker must use it.

Suggested change

Apply the guard the module already computes eleven lines above:

diff --git a/C910_RTL_FACTORY/gen_rtl/mmu/rtl/ct_mmu_regs.v b/C910_RTL_FACTORY/gen_rtl/mmu/rtl/ct_mmu_regs.v
index f9520ee..177a8d3 100644
--- a/C910_RTL_FACTORY/gen_rtl/mmu/rtl/ct_mmu_regs.v
+++ b/C910_RTL_FACTORY/gen_rtl/mmu/rtl/ct_mmu_regs.v
@@ -642,7 +642,7 @@ begin
     satp_asid[ASID_WIDTH-1:0] <= {ASID_WIDTH{1'b0}};
     satp_ppn[PPN_WIDTH-1:0]   <= {PPN_WIDTH{1'b0}};
   end
-  else if(satp_write_en)
+  else if(satp_write_en && cp0_mmu_wdata[62:60] == 3'b0)
   begin
     satp_asid[ASID_WIDTH-1:0] <= cp0_mmu_wdata[59:44];
     satp_ppn[PPN_WIDTH-1:0]   <= cp0_mmu_wdata[PPN_WIDTH-1:0];

That block is a file git apply will take from the repository root, checked against b91c909 as it stands rather than being retyped here. sha256 7fad1b49639cff090fa189646ddf0ef0a44123021d4a4f81c655343eb6c877b7 is over exactly those bytes, so sha256sum on what you paste says whether you have the same file we applied. No line of it carries trailing whitespace, so an ordinary copy out of this page is enough.

The one hunk touches only the satp_asid and satp_ppn write block in ct_mmu_regs.v; it does not overlap any other region of that file.

Nothing new is computed and no signal is introduced. We re-elaborated the entire SoC from this patched source and re-ran the same seven cases on the same simulator; the reproduction comment carries every line of both runs under The whole output, with the suggested change applied. The four rejected writes become no-ops and both controls are byte-identical to the run above:

C 0x801110000000aaaa 0x801110000000aaaa    // the MODE=9 probe write no longer moves ASID or PPN
D 0x801110000000aaaa 0x801110000000aaaa    // MODE=1
E 0x801110000000aaaa 0x801110000000aaaa    // MODE=10
F 0x001110000000aaaa 0x001110000000aaaa    // MODE=9 written from Bare
B 0x801110000000aaaa 0x802220000000bbbb    // control: the supported-MODE write still lands in full
G 0x801110000000aaaa 0x006660000000ffff    // control: the Bare write still lands in full
TRAPS 0x0000000000000000                   // nothing is achieved by trapping a write 1.10 requires to be ignored

We are reporting a divergence, not prescribing a fix — whether this is the right change under your constraints is your call.

The change does not touch regs_utlb_clr at :238, and we are not asking for that line to change. Once the rejected write is a no-op, flushing the micro-TLB on it costs a re-walk and nothing more; it is architecturally harmless. It is quoted above because it removes an alternative explanation for the readback, not because it is part of the finding.

[dreamqin68]

Reproduction — satp partial update

Everything below is derived from the runs that produced the report: the programs are the sources that were assembled, the output is the whole of what the simulation printed, and each digest is over the text as quoted here.

Environment

what	value
simulator	Verilator 5.048 2026-04-26 rev v5.048
simulator image	verilator/verilator:v5.048 (Apptainer)
compiler	riscv64-unknown-elf-gcc (13.2.0-11ubuntu1+12) 13.2.0
compiler target	riscv64-unknown-elf
ISA string	rv64imafdc
source files elaborated	536
flow	the vendor's own smart_run Verilator flow
vendor testbench	smart_run/logical/tb/tb_verilator.v
vendor testbench sha256	fddf65cbd13688cc0b27f854792e5daf8937b918449c08a9bdd6f2649b8a12d3
vendor testbench modified	false

The testbench line is a digest rather than a git status: a clean working tree says nobody edited the file after the run, and a digest says which bytes the run read.

The simulation driver is the vendor's own logical/tb/sim_main1.cpp, unmodified, on every run quoted here -- it is in the elaboration command printed below. That it changes nothing against the driver this campaign used previously is checked rather than claimed: the same programs were run both ways on this simulator and every transcript came out byte-identical.

That comparison covers 12 transcripts, from the 3 elaborations that were run both ways.

One edit is made to the outputs below: paths under the harness directory are written as $HARNESS, because Verilator prints the absolute path of the file that calls $finish. Nothing else in any transcript is altered.

Checked out at:

openc910 at b91c90914c19f114d35c8f6b73408eb241ed847c

Commands

# 1. Elaborate the whole SoC, in verilator/verilator:v5.048 (Apptainer), from a directory beside smart_run/logical
verilator -x-assign 0 -Wno-fatal -Wno-TIMESCALEMOD --no-timing --threads 4 -cc --exe --top-module top -f ../logical/filelists/ip.fl -f ../logical/filelists/smart.fl +libext+.v+.h+.V+.sv+ +incdir+../logical/tb+ -y ../logical/tb ../logical/tb/tb_verilator.v ../logical/tb/sim_main1.cpp +define+NO_DUMP
cp ../logical/tb/Makefile_obj ./Makefile_obj
make -j$(nproc) -C obj_dir -f ../Makefile_obj

# 2. Build the test program, with riscv64-unknown-elf-gcc (13.2.0-11ubuntu1+12) 13.2.0
riscv64-unknown-elf-gcc -march=rv64imafdc -mabi=lp64d -nostdlib -nostartfiles \
    -T $HARNESS/link_fullcore.ld $HARNESS/<program>.S -o <program>.elf
riscv64-unknown-elf-objcopy -O srec <program>.elf <program>_inst.hex -j .text -j .rodata
smart_run/tests/bin/Srec2vmem <program>_inst.hex inst.pat
: > data.pat

# 3. Run, with inst.pat and data.pat beside the model
smart_run/work/obj_dir/Vtop

The programs

link_fullcore.ld — sha256 86d6ece3c668e065e801d6d415f2c89b5807d5fcb5f9e0d812883336f0e6ce80

/* Linker script for programs run on the OpenC910 smart_run full-core testbench.
 *
 * The memory map is NOT a choice made here. It is dictated by
 * smart_run/logical/tb/tb_verilator.v, which loads inst.pat into the large AXI
 * SRAM starting at row 0 and data.pat starting at row 0x4000 -- and each row of
 * that SRAM is 16 bytes, so the data region begins at byte 0x40000. The two
 * regions below are the vendor's own linker.lcf regions, reproduced rather than
 * included so this unit's program does not depend on the vendor case-build
 * makefile (which needs a T-Head toolchain this container does not have).
 *
 * __start must land at address 0x0: that is where the core fetches after reset.
 */

MEMORY
{
  MEM1 (RWX) : ORIGIN = 0x00000000, LENGTH = 0x40000
  MEM2 (RWX) : ORIGIN = 0x00040000, LENGTH = 0xc0000
}

ENTRY(__start)

SECTIONS
{
  .text :
  {
    *(.text.init)
    *(.text*)
  } >MEM1

  .rodata :
  {
    *(.rodata*)
    *(.srodata*)
  } >MEM1

  .data :
  {
    *(.data*)
    *(.sdata*)
  } >MEM2

  .bss :
  {
    *(.bss*)
    *(.sbss*)
    *(COMMON)
  } >MEM2

  end = .;
}

satp_fullcore_witness.S — sha256 36e772814df790f683bafa6332481c83703932296ec0e870d94d9c58fc1b7233

// Full-core witness for the satp unsupported-MODE class.
//
// This is the SAME case matrix as openc910_satp_partial_update_replay (cone) and
// openc910_satp_partial_update_spike (reference), run this time on the whole
// OpenC910 SoC booting from reset, with nothing forced and nothing stubbed. The
// program writes satp and reads it back with ordinary csrw/csrr from M-mode and
// prints what it read through the testbench's character port at 0x01fffff0.
//
// Nothing here is privileged trickery. That is the point of the class: the write
// is a plain supervisor-address-translation-register write that any M-mode
// software may perform, and the readback is the architectural interface. If the
// cone result reproduces here, the divergence is reachable by software rather
// than only by driving a module's ports.
//
// Output format, one line per case:
//
//     <letter> <satp after setup write> <satp after probe write>
//
// then a final line "TRAPS <count>" and "DONE". A trap anywhere in the sequence
// is a failure of the measurement, not a result: M-mode csrw/csrr on satp must
// not trap, and the count exists so that a silent one cannot be mistaken for a
// clean run.
//
// Plain rv64imafdc. No T-Head custom instruction and no custom CSR.

#define PRINT_PORT 0x01fffff0

    .section .text.init, "ax"
    .globl __start
__start:
    li      sp, 0xee000

    la      t0, trap_handler
    csrw    mtvec, t0
    li      s11, 0                      // trap counter

    la      s0, case_table
    li      s1, 7

case_loop:
    ld      s2, 0(s0)                   // letter
    ld      s3, 8(s0)                   // setup value
    ld      s4, 16(s0)                  // probe value
    ld      s5, 24(s0)                  // 1 if this case makes a probe write

    csrw    satp, s3
    csrr    s6, satp                    // satp after the setup write

    beqz    s5, no_probe
    csrw    satp, s4
no_probe:
    csrr    s7, satp                    // satp after the probe write

    mv      a0, s2
    call    putc
    li      a0, 32
    call    putc
    mv      a0, s6
    call    puthex64
    li      a0, 32
    call    putc
    mv      a0, s7
    call    puthex64
    li      a0, 10
    call    putc

    addi    s0, s0, 32
    addi    s1, s1, -1
    bnez    s1, case_loop

    // TRAPS <count>
    li      a0, 84                      // 'T'
    call    putc
    li      a0, 82                      // 'R'
    call    putc
    li      a0, 65                      // 'A'
    call    putc
    li      a0, 80                      // 'P'
    call    putc
    li      a0, 83                      // 'S'
    call    putc
    li      a0, 32
    call    putc
    mv      a0, s11
    call    puthex64
    li      a0, 10
    call    putc

    // DONE
    li      a0, 68
    call    putc
    li      a0, 79
    call    putc
    li      a0, 78
    call    putc
    li      a0, 69
    call    putc
    li      a0, 10
    call    putc

    // The vendor testbench finishes with TEST PASS on this exact value crossing
    // an integer writeback port. It is reached unconditionally: this program
    // reports measurements and does not adjudicate them, so PASS here means the
    // run completed, NOT that the readbacks matched anything.
    li      t0, 0x444333222
    add     t1, x0, t0
spin:
    j       spin

// a0 = character. Clobbers t0 only, so callers may keep values in t1/t2.
putc:
    li      t0, PRINT_PORT
    sw      a0, 0(t0)
    ret

// a0 = 64-bit value, printed as 16 lower-case hex digits.
puthex64:
    addi    sp, sp, -16
    sd      ra, 0(sp)
    sd      s8, 8(sp)
    mv      s8, a0
    li      t1, 60
puthex_digit:
    srl     a0, s8, t1
    andi    a0, a0, 0xf
    li      t2, 10
    blt     a0, t2, puthex_dec
    addi    a0, a0, 87                  // 'a' - 10
    j       puthex_emit
puthex_dec:
    addi    a0, a0, 48                  // '0'
puthex_emit:
    call    putc
    addi    t1, t1, -4
    bgez    t1, puthex_digit
    ld      s8, 8(sp)
    ld      ra, 0(sp)
    addi    sp, sp, 16
    ret

    .align  2
trap_handler:
    // An M-mode csrw/csrr on satp must not trap. Count it and resume at the
    // instruction after the faulting one so the remaining cases still report.
    addi    s11, s11, 1
    csrr    t0, mepc
    addi    t0, t0, 4
    csrw    mepc, t0
    mret

    .section .rodata
    .align  3
    // letter, setup value, probe value, probe-is-made
    //
    // Identical to the cone replay's matrix. A and G and B are the controls: a
    // supported MODE must land in full, or the harness is not driving the write
    // path and nothing may be concluded from C, D, E, F.
case_table:
    .dword 65, 0x801110000000aaaa, 0x0000000000000000, 0   // A: no probe
    .dword 66, 0x801110000000aaaa, 0x802220000000bbbb, 1   // B: MODE 8 supported
    .dword 67, 0x801110000000aaaa, 0x902220000000bbbb, 1   // C: MODE 9 Sv48
    .dword 68, 0x801110000000aaaa, 0x103330000000cccc, 1   // D: MODE 1 reserved
    .dword 69, 0x801110000000aaaa, 0xa04440000000dddd, 1   // E: MODE 10 Sv57
    .dword 70, 0x001110000000aaaa, 0x905550000000eeee, 1   // F: from Bare, MODE 9
    .dword 71, 0x801110000000aaaa, 0x006660000000ffff, 1   // G: MODE 0 supported

vehicle_check.S — sha256 721c6aa05a4792061871e7e0dc2897d7e5374b48ede724770a7af47ca0ad524d

// Bring-up check for the OpenC910 full-core vehicle. Proves nothing about satp.
//
// This program exists so that a later negative result on the real witness can be
// distinguished from a dead harness. It boots on the full core at reset, writes
// a string through the testbench's character port at 0x01fffff0, and then puts
// the vendor's PASS magic value on the integer writeback bus. If the transcript
// shows the string AND "simulation finished successfully", then instruction
// fetch, retirement, the store path to the AXI slave, and the testbench's two
// observation channels are all live.
//
// Plain rv64imafdc: no T-Head custom instruction and no custom CSR is used, so
// it builds with an upstream toolchain. The vendor's own crt0.s cannot be used
// here because it opens with `csrs mxstatus` and `sync`, which an upstream
// assembler does not accept.

    .section .text.init, "ax"
    .globl __start
__start:
    li      sp, 0xee000

    la      a0, msg
1:
    lbu     a1, 0(a0)
    beqz    a1, 2f
    li      a2, 0x01fffff0
    sw      a1, 0(a2)
    addi    a0, a0, 1
    j       1b
2:

    // The vendor testbench finishes with TEST PASS when this exact value
    // appears on an integer writeback port. tb_verilator.v watches
    // rbus_pipe0_wb_data / rbus_pipe1_wb_data; the redundant `add` guarantees a
    // full 64-bit value crosses one of them rather than only the tail of the
    // `li` expansion.
    li      t0, 0x444333222
    add     t1, x0, t0
3:
    j       3b

    .section .rodata
msg:
    .asciz "VEHICLE-OK\n"

The whole output

vehicle_check is a bring-up program: it exercises the character port and the load path and touches none of the registers this report is about. It runs on every build below, so a build that had been broken by the change rather than corrected by it would say so here, independently of every value above.

satp_fullcore_witness — as printed, in full — sha256 0162cf49c4ebc94f4136f2c371d89bcd7638ac107a161187cd6bc86b94a775cb

	********* Init Program *********
	********* Wipe memory to 0 *********
	********* Read program *********
	********* Load program to memory *********
A 801110000000aaaa 801110000000aaaa
B 801110000000aaaa 802220000000bbbb
C 801110000000aaaa 802220000000bbbb
D 801110000000aaaa 803330000000cccc
E 801110000000aaaa 804440000000dddd
F 001110000000aaaa 005550000000eeee
G 801110000000aaaa 006660000000ffff
TRAPS 0000000000000000
DONE
**********************************************
*    simulation finished successfully        *
**********************************************
- ../logical/tb/tb_verilator.v:315: Verilog $finish

vehicle_check — as printed, in full — sha256 e9819f597a7c743d13384cb4ad10bff0fc9e8b4f71f184172f5837567b6ce5ee

	********* Init Program *********
	********* Wipe memory to 0 *********
	********* Read program *********
	********* Load program to memory *********
VEHICLE-OK
**********************************************
*    simulation finished successfully        *
**********************************************
- ../logical/tb/tb_verilator.v:315: Verilog $finish

The whole output, with the suggested change applied

The body above quotes this run. It is the same simulator, the same programs, the same testbench and the same driver as everything above; the one difference is that one entry of the RTL filelist points into $PATCHED, a directory holding one file: the vendor's, with the diff from the report's Suggested change section applied. The vendor tree itself is never edited, which is why the command names a path outside it rather than being the command above run against a modified checkout. Applying that diff to a clean clone and running the unpatched command reaches the same source. The elaboration differs from the one above in that argument alone:

verilator -x-assign 0 -Wno-fatal -Wno-TIMESCALEMOD --no-timing --threads 4 -cc --exe --top-module top -f $PATCHED/C910_asic_rtl_patched.fl -f ../logical/filelists/smart.fl +libext+.v+.h+.V+.sv+ +incdir+../logical/tb+ -y ../logical/tb ../logical/tb/tb_verilator.v ../logical/tb/sim_main1.cpp +define+NO_DUMP

The two elaborations produced different binaries, which is checked rather than assumed: 0fea1584158901ed9005d4996299251ab7b5a997794fb1ce15848a5a5e5f5525 unpatched against 060607df2cad20781305f782b47a8b4e6a6d93693bb8f438924d5a06d5baca2f patched.

satp_fullcore_witness, patched — as printed, in full — sha256 6717844be7ef744f983b65a086521f8fb674350291d010446616004d3f8a9d56

	********* Init Program *********
	********* Wipe memory to 0 *********
	********* Read program *********
	********* Load program to memory *********
A 801110000000aaaa 801110000000aaaa
B 801110000000aaaa 802220000000bbbb
C 801110000000aaaa 801110000000aaaa
D 801110000000aaaa 801110000000aaaa
E 801110000000aaaa 801110000000aaaa
F 001110000000aaaa 001110000000aaaa
G 801110000000aaaa 006660000000ffff
TRAPS 0000000000000000
DONE
**********************************************
*    simulation finished successfully        *
**********************************************
- ../logical/tb/tb_verilator.v:315: Verilog $finish

vehicle_check, patched — as printed, in full — sha256 e9819f597a7c743d13384cb4ad10bff0fc9e8b4f71f184172f5837567b6ce5ee

	********* Init Program *********
	********* Wipe memory to 0 *********
	********* Read program *********
	********* Load program to memory *********
VEHICLE-OK
**********************************************
*    simulation finished successfully        *
**********************************************
- ../logical/tb/tb_verilator.v:315: Verilog $finish

$HARNESS is wherever the sources above are placed; every other path is relative to the root of the openc910 checkout.