K3 Architecture Bug: mepc Loses bit63 on Instruction Page Fault with Non-Canonical Addresses

Community member sw123456 discovered and reported a subtle but significant architecture compliance issue on the SpacemiT K3: when an instruction page fault occurs on a non-canonical virtual address under Sv39, the mepc register loses bit63, returning a Sv39-normalized address instead of the full 64-bit virtual address required by the RISC-V specification.

The Bug

Test environment: K3 platform, S-mode, Sv39 paging. Execute a jalr to the non-canonical virtual address 0x8000000150009000.

Expected behavior (per RISC-V Privileged Architecture):

mcause = 12 (instruction page fault)
mtval = 0x8000000150009000 (full faulting VA)
mepc = 0x8000000150009000 (full 64-bit virtual address of the faulting instruction)

Actual behavior on K3:

mcause = 12 (correct)
mtval = 0x8000000150009000 (correct)
mepc = 0x0000000150009000 (bit63 lost — Sv39-normalized)

The mepc value equals the PC after Sv39 canonicalization (sign-extending from bit38). This means K3 writes the "normalized" address into mepc rather than the original 64-bit architectural PC.

Why This Matters

The RISC-V Privileged Architecture states:

> "When a trap is taken into M-mode, mepc is written with the virtual address of the instruction that was interrupted or that encountered the exception."

This requires the full 64-bit virtual address. The mtval definition is consistent: it correctly stores the full faulting VA on K3, so mepc should match.

The WARL clause ("mepc is a WARL register that must be able to hold all valid virtual addresses... implementations may convert an invalid address into some other invalid address that mepc is capable of holding") does not excuse this behavior. That clause permits invalid-to-invalid conversion; K3 instead produces a "legally-formed" address that could be mistaken for a valid canonical address. The official RISC-V architecture compliance suite (SAIL model) confirms the expected behavior:

translate_validate_address() detects the non-canonical address and raises PTW_Invalid_Addr
excinfo = zero_extend(bits_of(gva)) — mtval gets the full VA
mepc = pc — the full 64-bit PC is written

Impact

For most application code this bug is invisible — non-canonical addresses are typically unreachable in well-behaved programs. However, for:

OS developers handling edge cases in virtual-memory subsystems
Security researchers analyzing trap handlers
Architecture compliance testing
Hypervisors managing guest OSes with creative address layouts

...the discrepancy between mepc and mtval can cause subtle failures in exception handlers that expect both registers to agree on the faulting address.

Workaround

Until a silicon or microcode fix is available, trap handlers that need the full faulting address on K3 should prefer mtval over mepc for instruction-page-fault cases. Note that this is a K3-specific quirk and should be guarded by machine-specific detection.

Source: K3 取指页错误时mepc丢失 bit63(非规范地址被 Sv39 规范化) by sw123456 Looking for RISC-V hardware and development boards? Visit open-riscv.com for SpacemiT K1/K3, WCH CH32V series, and more.