[davidharrishmc]

Implements Svvptc, an RVA23 option. Wally's walker wrote the entry for an invalid PTE (V=0, at any level) into the I-TLB/D-TLB, so the replayed access kept faulting until SFENCE.VMA or eviction; Svvptc requires stores that set V from 0 to 1 to become visible to later implicit accesses in bounded time (norm:Svvptc_explicit_stores_update_valid_bit).

• hptw.sv: InvalidPTEFaultM sends LEAF to FAULT, blocks the TLB write, and raises the page fault through the existing walk-fault path (which already handles fetch spills, misaligned spills and pending walks).
• tlbcontrol.sv: ~PTE_V drops out of the hit-path page fault (the TLB can no longer hold V=0); the ITLB ADUE coverage-exclusion row moves accordingly.
• V=1 PTEs that fault for other reasons (permissions, U/SUM, A/D under Svade, reserved bits, PBMT/NAPOT, misaligned superpages) are still cached; Svvptc covers only V 0→1.
• Declares Svvptc in the rv32gc/rv64gc ACT UDB yamls (sail.json already did).

Found by FORCE-RISCV in ImperasDV lockstep. The FORCE reproducers and directed load/store/fetch, leaf/non-leaf, fetch-spill and misaligned-spill tests pass (also on Sail); the new ACT Svvptc suite (riscv/riscv-arch-test#2776) fails on rva23 and passes with this change; lockstep over all rv64gc/rv32gc Sv priv suites, Misalign and coverage tests shows only the existing Svnapot waivers; Verilator regression and lint-wally are unchanged.

🤖 Generated with Claude Code

[rosethompson]

This is an interesting change. Originally the hptw did not write invalid entries into the TLB. We switched it because an ITLB fault would occur multiple times for each instruction in the pipeline until the faulting instruction made it to the Memory stage wasting many cycles. With this change we should also prevent the subsequent instruction fetches from making requests until the ITLB fault makes it to the Memory stage.