Conflicting sentences about mvip[9] and mip[9] when mvien[9]=0

[YenHaoChen]

The spec says that "when mvien[9]=0, mvip[9] is an alias of mip[9]" and "when mvien[9]=0, mvip[9] is logically ORed into the readable value of mip[9]."

In my reading, aliasing bits means identical bits and logically ORed means bits may differ. For instance, if mip[9] and mvip[9] are aliasing bits, the value pair of (mip[9], mvip[9]) can be (0, 0) and (1, 1) only. On the other hand, if mip[9] logically ORs the mvip[9] into the readable value, the value pair of (mip[9], mvip[9]) can be (0, 0), (1, 0), and (1, 1).

Is the value pair of (mip[9], mvip[9]) = (1, 0) a valid state when mvien[9]=0?

[jhauser-us]

I agree that this case is confusing. However, the source of the confusion is actually found in the main RISC-V Privileged ISA, which specifies that there is a software-writable SEIP bit that contributes to the readable value of mip.SEIP (mip bit 9). Unfortunately, although you can change the value of this software-writable SEIP bit by writing to mip, the Privileged ISA provides no way to directly read this bit. It exists partly hidden behind mip.SEIP.

Here's what the Privileged ISA says:

SEIP is writable in mip, and may be written by M-mode software to indicate to S-mode that an external interrupt is pending. Additionally, the platform-level interrupt controller may generate supervisor-level external interrupts. Supervisor-level external interrupts are made pending based on the logical-OR of the software-writable SEIP bit and the signal from the external interrupt controller. When mip is read with a CSR instruction, the value of the SEIP bit returned in the rd destination register is the logical-OR of the software-writable bit and the interrupt signal from the interrupt controller, but the signal from the interrupt controller is not used to calculate the value written to SEIP. Only the software-writable SEIP bit participates in the read-modify-write sequence of a CSRRS or CSRRC instruction.

You wrote:

The spec says that "when mvien[9]=0, mvip[9] is an alias of mip[9]" and "when mvien[9]=0, mvip[9] is logically ORed into the readable value of mip[9]."

Look again at the parts of the AIA you highlighted. In fact, what the AIA says is:

When bit 9 of mvien is zero, bit 9 of mvip is an alias of the software-writable bit 9 of mip (SEIP).

You changed "software-writable bit 9 of mip" to just "mip[9]", which changes the meaning. The AIA is speaking of that strange, partly hidden SEIP bit specified by the Privileged ISA.

When mvien[9] = 0, the AIA is trying to improve the situation by making that partly hidden bit directly readable and writable in mvip[9]. (And when mvien[9] = 1, the AIA simplifies matters further by changing the rules so that mvip[9] no longer contributes to mip.SEIP at all.)

[YenHaoChen]

Thank you for the clear clarification.

1. The mip[9] itself is a software-writable bit and is special in its read value, which is the logical-OR of itself and the other source from the interrupt controller (when mvien[9]=0).
2. The mvip[9] is an alias of the software-writable bit of mip[9] itself and is independent of the other source from the interrupt controller. (The mvip[9] is the only way for software to explicitly read the software-writable bit of mip[9] itself through CSR instructions.)
3. When mvien[9]=1, the read value of mip[9] is no longer the logical-OR but the other source from the interrupt controller only, i.e., the read value of mip[9] is independent of the software-writable bit itself, alias of mvip[9].

@jhauser-us Are the above correct? Thank you again for your time and patience.

[jhauser-us]

Yes, it sounds like you understand.

[YenHaoChen]

Thank you