Fix guest page fault cause without RVC

[124107157-KV]

• I have searched for similar pull requests
• I am a human engaging in an interpersonal interaction. During this interaction, my words are my own and are not generated. If relevant, I provide links to my sources.

Why is this PR needed?

When the hypervisor extension is enabled and the compressed-instruction extension is disabled (RVH=1, RVC=0), the non-RVC path in instr_queue incorrectly maps an incoming FE_INSTR_GUEST_PAGE_FAULT to riscv::INSTR_PAGE_FAULT.

This changes the architectural exception cause from instruction guest-page fault (mcause = 20) to instruction page fault (mcause = 12).

The RVC-enabled path already preserves FE_INSTR_GUEST_PAGE_FAULT correctly. The equivalent mapping was missing from the non-RVC path.

What does this PR change?

The non-RVC exception mapping in core/frontend/instr_queue.sv now handles FE_INSTR_GUEST_PAGE_FAULT explicitly when the hypervisor extension is enabled.

The resulting mapping is:

FE_INSTR_ACCESS_FAULT
    -> riscv::INSTR_ACCESS_FAULT

FE_INSTR_GUEST_PAGE_FAULT with RVH enabled
    -> riscv::INSTR_GUEST_PAGE_FAULT

Other fetch page faults
    -> riscv::INSTR_PAGE_FAULT

A directed RV64 regression is also added for the RVH=1, RVC=0 case.

The regression configures pure G-stage translation using:

vsatp = Bare
hgatp = Sv39x4

It installs a valid G-stage leaf mapping for the guest instruction address with execute permission disabled. Entering VS-mode therefore causes a G-stage instruction-fetch permission fault.

The M-mode trap handler reads mcause and checks that the architectural exception remains instruction guest-page fault, cause 20.

The result is written directly to tohost without using a taken branch before termination.

Verification

The regression was checked against Spike and against CVA6 with the hypervisor extension enabled and hardware RVC disabled.

Spike reference

Spike reports the expected exception:

trap_instruction_guest_page_fault
epc = 0x000000008000020c

CVA6 with this fix

The first exception reaches the M-mode handler with:

mcause = 20

The directed regression then writes the passing result to tohost.

Observed result:

*** SUCCESS *** (tohost = 0) after 788 cycles
FIXED_RC=0

CVA6 with pristine upstream RTL

The same regression and hardware configuration were also run after temporarily restoring the pristine upstream version of core/frontend/instr_queue.sv.

The upstream RTL reports:

INSTR_PAGE_FAULT
mcause = 12

The regression fails as expected:

*** FAILED *** (tohost = 12) after 788 cycles
BUGGY_RC=1

This reproduces issue #3568 and confirms that the RTL change preserves the architectural instruction guest-page-fault cause.

Configuration note

The repository currently does not provide a directly runnable predefined RV64 simulation target combining RVH=1 with hardware RVC=0.

For the before/after CVA6 validation, cv64a6_imafdch_sv39 was used while temporarily setting CVA6ConfigCExtEn=0 and keeping CVA6ConfigHExtEn=1.

That temporary configuration change was restored after testing and is not part of this pull request.

The directed assembly regression also uses .option norvc so that the test program itself does not contain compressed instructions.

Files changed

• core/frontend/instr_queue.sv
• verif/tests/custom/issues/instr-guest-page-fault-rvc0-rv64.S
• verif/tests/testlist_issues.yaml

Fixes #3568