RISC-V Address-Space Changes: Invalidate the Intended Translation Scope Before Reusing an ASID

A supervisor reuses an address-space identifier for a new page-table root, writes satp and then accesses memory through an old translation. The new root value can be correct while cached translations remain valid from the hardware's perspective.

The repair requires the right translation-fence scope and ordering. An instruction-fetch fence or a generic belief that switching address spaces flushes everything does not establish that contract.

Writing satp does not implicitly flush translations

The Supervisor-Level ISA 1.13 specification explicitly states that writing satp neither orders page-table updates against subsequent translation nor invalidates address-translation caches by itself.

For ASID reuse, one documented sequence loads the new root and recycled ASID into satp, then executes SFENCE.VMA for all virtual addresses in that ASID. The specification also permits an earlier fence under another active ASID, provided the next use of the recycled ASID simultaneously installs its new root.

Keep that association visible in the address-space switch code. A fence for an identifier followed by another activation of its old root defeats the intended reuse sequence.

x0 selects scope; a register containing zero selects ASID zero

SFENCE.VMA uses its operand identities to choose scope. With both operands x0, it covers all virtual addresses and address spaces, including global mappings.

With the address operand x0 and a non-x0 ASID register, it covers all addresses for the specified ASID but excludes global mappings. If that register contains zero, the operation targets ASID zero; it does not acquire the all-ASID semantics of encoding x0 itself.

For a hypothetical reused ASID 7, sfence.vma x0, t0 with t0=7 expresses the all-addresses, ASID-7 operation. The operand must contain the intended ASID with the specified upper bits handled correctly, rather than a page-table pointer or a software process number.

Match leaf, non-leaf and global changes

A changed leaf mapping can be fenced using a virtual address within that mapping. A non-leaf page-table change requires the wider all-address scope described by the specification. Restricting such a change to one apparent leaf address can leave translations derived from the replaced subtree outside the intended invalidation.

If any PTE along the translation path has its global bit set, the ASID operand must be x0 for the documented update procedure. An ASID-specific fence excludes global mappings, even when software considers that global mapping part of the process currently being changed.

Implementations may legally over-fence. A simple core that flushes more than requested can hide an underscoped software operation. Portability requires the scope that the architecture guarantees, not the broader behavior observed on one processor.

Complete the corresponding operation on other users

SFENCE.VMA affects the local hart's translation references. The specification describes a remote-update pattern using a data fence, notification to other harts, their local translation fences and completion signalling back to the initiator.

The ratified SBI v3.0 RFENCE extension provides remote SFENCE.VMA calls, including an ASID-specific form. Check target selection, address range and returned errors under the platform's supported shootdown protocol before reusing memory whose old translation may still be accessible elsewhere.

ASID meaning is local to a hart. If software assigns different numerical ASIDs to the same address space on different harts, one shared ASID value cannot blindly describe every remote target. Preserve the runtime's per-hart association when constructing remote requests.

A proposed review traces one reused identifier from old root through new-root installation, local scope and remote completion. Test global and non-leaf changes separately from a single leaf replacement. No page tables, satp registers or translations were changed here.