RISC-V Page Access Tracking: Do Not Treat PTE A and D Bits as an Execution Log

A page-replacement test finds an accessed bit set even though the application never completed its planned load. Another platform faults on the first access to a valid mapping whose permissions look correct. These observations can come from different architectural schemes for maintaining page-table accessed and dirty state.

The contract examined here is the Supervisor-Level ISA version 1.13, leaf PTE A/D management and translation algorithm, pinned at commit ff6bb3c. The discussion assumes ordinary, nonvirtualized single-stage translation. It is a source-derived review of paging software, not a tested page-replacement algorithm or a recommendation to modify a running product’s tables.

Identify the active update scheme first

A leaf PTE has an accessed bit, A, and a dirty bit, D. The architecture defines two ways to establish those bits when an access needs them. The faulting scheme, Svade, raises a page-fault exception when the page is accessed with A=0, or written with D=0.

Under the hardware-update scheme, the translation machinery instead updates the PTE to set the required bits, subject to its checks. A page-fault handler designed around first-access faults cannot assume every implementation will generate them automatically. Conversely, software expecting hardware updates can encounter legitimate page faults on a platform using Svade.

The Machine-Level ISA 1.13 environment configuration adds another configuration detail when Svadu is implemented: menvcfg.ADUE=1 enables hardware A/D updating, while zero disables it and yields Svade behavior. Record the implemented extensions and installed machine-firmware policy. The supervisor cannot infer the active scheme merely from seeing a writable leaf or successful earlier reads.

The specification also requires all harts in a system to employ the same PTE-update scheme. A migration or firmware handoff record should therefore describe the system contract, not only the first hart used for a smoke test.

An accessed bit may reflect speculation

Under hardware updating, an A-bit update may happen speculatively even if the corresponding memory access is never performed architecturally. This supports mechanisms such as translation prefetching and means A=1 is not evidence that a particular load retired or an application consumed the page’s contents.

That distinction matters when validating an eviction policy or investigating an unexpected page touch. The bit is useful for the page-management purpose defined by the operating system, but it is not a precise trace record with an instruction identity or completion timestamp.

Construct a diagnostic claim narrowly: the mapping’s accessed state was observed set during the interval. To prove that the application read and processed a particular object, collect application-level completion evidence through a suitable, nonintrusive mechanism. Do not use the A bit alone as an audit or functional-execution oracle.

Original A/D-state model. It distinguishes translation metadata updates from the completion of an application memory operation.

Dirty-bit precision still does not make the update and store one operation

The specification imposes a stronger rule on D-bit updates caused by an explicit store: they must be exact, meaning non-speculative, and observed in program order by the local hart. Preserve that distinction rather than generalizing the A-bit speculation permission to dirty tracking.

However, the PTE update is not required to be atomic with the actual memory access that caused it. A trap can occur between the update and that access. The specification explicitly allows the A and/or D bit to be updated even though the associated memory access does not occur.

Thus “D updates are non-speculative” and “D proves this particular store completed” are different claims. The first follows the architectural contract for this scope; the second is too strong. Dirty metadata is not a transaction-commit flag for the application object mapped by the page.

This discussion intentionally excludes two-stage virtualization, where implicit accesses to another translation stage introduce additional D-bit rules. Do not apply the single-stage worksheet to guest page-table tracking without reviewing those rules separately.

Hardware must update the complete checked PTE atomically

Hardware A/D updates must be atomic with respect to other accesses to the PTE and must incorporate the page-walk checks for that leaf. The translation algorithm describes comparing the examined PTE with its current value, conditionally updating it and restarting the walk if the comparison fails.

That requirement prevents a hardware update from blindly adding bits to an entry that software has replaced or repurposed. It is not permission for software to overwrite the same entry with a stale saved value. A software writer still needs the operating system’s supported page-table locking, atomic-update and invalidation procedures.

The architecture also requires suitable page-table memory for hardware writes, including the specified physical-memory attributes. If updating the PTE would violate the applicable physical access checks, the resulting failure is not repaired by changing the mapped application’s ordinary read/write permission bits. Include the table’s own physical accessibility in the bring-up record.

Design separate fixtures for faulting and updating behavior

Start with an otherwise valid, permitted leaf and an isolated page whose lifecycle the test owns. For Svade, propose a read with A=0 and a store with A=1,D=0; expect the corresponding page-fault handling path before the access completes. For hardware updating, propose equivalent accesses and inspect the required A/D changes under the platform’s supported observation method.

A test cannot require speculative A updates to happen, because implementations may perform exact updates instead. It should tolerate allowed speculation without treating it as application completion. Likewise, do not attempt to force the trap-between-update-and-store case on a production system merely to prove that the allowed outcome exists.

The implementation never clears A or D on software’s behalf. When a policy clears them to begin another observation interval, use its established synchronization and translation-invalidation protocol. A bare memory store to a PTE does not define a portable new sampling epoch across all harts.

No page access, PTE modification or fault fixture was executed here. A useful acceptance record identifies the active update scheme, exact fault or update outcome and the limits of what A/D state proves. That keeps a legitimate first-access fault, a speculative A update and actual application completion from being collapsed into one misleading result.