RISC-V MPRV Helpers: Apply the Caller’s Memory Rules Without Changing Instruction Fetch

A machine-mode helper can continue executing its own instructions while a load from a caller’s address faults. That combination is expected when the helper deliberately changes the effective data-access context. MPRV does not move the entire routine into another privilege mode; it changes how its explicit loads and stores are interpreted.

The scope here is the Machine-Level ISA version 1.13 in specification library v20260120, particularly section 2.1.1.6.4. The model is nonvirtualized M-mode firmware servicing a supervisor or user context. It is a review framework, not a universal CSR-writing routine or a tested copy helper.

Draw instruction and data paths separately

With MPRV=0, explicit memory accesses use the current privilege mode’s normal translation and protection rules. With MPRV=1, load and store addresses are translated and protected as though the current privilege were the value in MPP.

The selected context also supplies endianness and the effective address-width behavior associated with that privilege’s XLEN. This is more than temporarily allowing a protected physical address. A virtual address can be interpreted through a different translation regime, and its address-width assumptions can change.

Instruction address translation and protection are unaffected by MPRV. An M-mode helper therefore keeps fetching its instructions under its execution context while its explicit data accesses use the selected effective context. A successful instruction fetch says nothing about whether the next caller-address load is valid under those different rules.

For each reviewed access, record the actual execution mode and effective data mode separately. A single field called “current privilege” can hide the distinction that explains the fault.

Use MXR for the page permission it actually changes

An emulation helper may need to read bytes from a page marked executable but not readable. With page-based virtual memory active, MXR=0 permits loads only through readable pages; MXR=1 also permits loads through executable pages, subject to all other applicable checks.

That is why the specification discusses MPRV and MXR together for machine-mode emulation. The helper can use the appropriate translation context and interpret executable permission as sufficient for the load’s page-level read check.

Do not describe MXR as making arbitrary memory readable. It has no effect when page-based virtual memory is not active, and it does not authorize stores to executable pages. A missing translation, another permission failure or physical access rejection remains a separate reason for failure.

In a proposed permission worksheet, an execute-only page with otherwise valid access should fail the load’s read-permission condition with MXR=0 and satisfy that condition with MXR=1. Label this as a conditional architectural prediction, not a successful memory probe.

Apply SUM when the effective data mode is supervisor

SUM controls supervisor loads and stores to user-accessible pages under page-based virtual memory. With SUM=0, those accesses fault; with SUM=1, this particular restriction is lifted, while the other checks still apply.

Although SUM is ordinarily ignored outside S-mode, the machine specification explicitly makes it effective when MPRV=1 and MPP=S. The helper’s instructions remaining in M-mode does not make the supervisor user-page rule disappear.

Do not use this to claim a full switch into the user’s execution environment. The effective mode is still the chosen MPP value, and the altered operation is the explicit data access. State why a helper needs supervisor interpretation of a user page instead of silently granting broader access to every pointer it receives.

Keep physical protection independent

The specification states that MXR and SUM affect the interpretation of page-table permissions. They do not change whether physical memory attributes or Physical Memory Protection cause access-fault exceptions.

A page-permission worksheet therefore needs a separate physical-access column. Marking a virtual page readable through MXR, or permitting supervisor access through SUM, cannot turn a physical rejection into an allowed access. Preserve the actual fault classification rather than collapsing every failed helper load into “bad page permissions.”

Include the helper’s own data accesses

The changed context affects explicit loads and stores in the sensitive interval, not just the one pointer the programmer intended to copy. Compiler-generated stack accesses, spilled registers or accesses to a diagnostic structure must be reviewed under that same effective context.

This is an implementation consequence of the architectural rule: the hardware does not recognize a special “caller data only” annotation on an ordinary load. Keep the interval deliberately bounded and inspect all data accesses that can occur within it, including supported recovery paths. Avoid adding logging that introduces unreviewed memory references there.

State restoration also needs an exact return condition. An MRET or SRET that changes privilege to below M clears MPRV. That is not a guarantee that every return instruction, including an M-mode return, clears it. Review explicit restoration and exception handling rather than relying on a blanket return assumption.

No CSR, protected memory or target instruction was exercised here. A useful acceptance artifact separates instruction fetch, selected data translation, page permissions, physical checks and restoration. It explains why the helper can keep running while a particular access is correctly rejected, without treating privileged execution as universal permission.