Skip to content

Possible AIA/VS-mode bugs: VSTOPI handling, vsireg permissions, and SIP/SIE CSR types #2152

@franhans

Description

@franhans

Hi @YenHaoChen and @binno ,

I’m developing a RISC-V processor and I’m responsible for the AIA implementation. I wrote C++ lockstep tests that run on our processor and on Spike and compare outputs to find discrepancies. During those tests I found several discrepancies that look like bugs in Spike’s AIA model. I’ve attached a patch that fixes the behavior I describe below; please review and let me know if my interpretation is incorrect.

  1. VSTOPI and interrupts in VS mode
    1.1 When VSTOPI is read from VS mode and VTI = 0, the value returned is not adjusted to reflect VS-mode causes. Reading VSTOPI from VS-mode should return adjusted (VS) causes.
    1.2 processor_t::take_interrupt uses VSTOPI but masks supervisor interrupts. The interrupt selected in take_interrupt depends on the value in VSTOPI, but Supervisor interrupts appear to be masked. Furthermore, VSTOPI reads sometimes return adjusted causes (if the interrupt was generated through the HVICTL CSR with VTI=1) and sometimes non-adjusted causes, that doesn't seem coherent.
    1.3 The code always adjusts VS interrupts in take_trap, which can cause some interrupts to be adjusted twice when combined with the VSTOPI adjustments above.
    1.4 The solution implemented in the patch is always return an adjusted cause from VSTOPI for VS-mode reads (all cases). If SSMAIA is implemented, rely on the adjusted VSTOPI value in processor_t::take_trap to decide interrupts when the hart is in V mode. This keeps reads and trap selection coherent and avoids double-adjusting.

  2. Missing virtual-instruction-exception case in sscsrind_reg_csr_t::verify_permissions. The verify_permissions implementation does not check: “When vsiselect is in the range 0x30–0x3F, an attempt from VS-mode to access sireg (really vsireg) causes a virtual instruction exception.” I added this check in the patch.

  3. SIP and SIE registers must be declared using the type "virtualized_with_special_permission_csr_t" instead of virtualized_csr_t.

Thanks — I’d appreciate feedback on whether these are real Spike bugs or mistakes on my side.

spike_aia.patch

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions