Is SIP.SEIP (bit 9) read only when aliased to MVIP?

[jrahmeh]

The AIA spec section 5.3 states:
For interrupts 0–12, aliases in sip may be read-only, as specified by the RISC-V Privileged Architecture.

This may be interpreted as saying that some of the 0-12 interrupts are allowed to be read-only in SIP, when aliased to MVIP, just like they are in the privileged spec. Or it can be interpreted as saying that SIP bits aliased to MVIP must be read only if they are so in the privileged spec.

Which is it? Is SIP.SEIP read only when aliased to MVIP?

[kdockser]

@jrahmeh The latest version of the AIA spec (revised 20250312) says:
For interrupts 0-12, some aliases of mip bits in sip may be read-only copies, as specified by the base Privileged Architecture.

This seems to be a non-normative reminder of what is said in the privileged ISA, and not new information.

[jrahmeh]

@kdockser The "may be" is vague. Does it mean "permitted to be" or does it mean "required to be". Is SIP.SEIP read only when aliased to MVIP.SEIP?

[kdockser]

@jhauser-us We need your help on this.
Is the AIA sentence For interrupts 0-12, some aliases of mip bits in sip may be read-only copies, as specified by the base Privileged Architecture. just a non-normative reference to the privileged spec sentence Each individual bit in register sip may be writable or may be read-only.?
In each case, is the intention that which sip bits are read-only, for example, depends on the context?

[jhauser-us]

Is the AIA sentence ... just a non-normative reference to the privileged spec sentence "Each individual bit in register sip may be writable or may be read-only."?

Doesn't the Privileged spec also make these more specific statements in the same section?:

If implemented, SEIP is read-only in sip

If implemented, STIP is read-only in sip

If implemented, SSIP is writable in sip

The reason the caption to that table in the AIA says,

For interrupts 0-12, some aliases of mip bits in sip may be read-only copies, as specified by the base Privileged Architecture."

is because the implication would otherwise be that bits SEIP, STIP, and SSIP of sip must all be writable, being that they are indicated in the table as "aliases" of writable bits in mip. The totality of the table and its caption are trying to be succinct and to avoid misleading readers. That caption is already pretty long, and I thought it best not to lengthen and complicate it any further.

If you want to know which "aliased" bits in the range 0-12 "may be" read-only copies, go read the Privileged ISA document. For the current set of standardized bits, it says exactly which are read-only and which are writable. There's no guessing or freedom to choose.

[kdockser]

Thanks for the clarification, John.

While the text in the privileged spec is clear, I know a lot of people who thought that table 11 superceded what was in the privileged spec. Changing the "may be" --- which denotes a possibility --- to "are" --- which denotes certainty --- would add some more clarity:

For interrupts 0-12, some aliases of mip bits in sip are read-only copies, as specified by the base Privileged Architecture.

Even better would be a non-normative statement after the table that explicitly points out out the exceptions to the bottom row of the table: when mideleg[n]=1 SIP[SEIP, STIP, SSIP] are read only copies of the corresponding bits in mip.

[jhauser-us]

I'm sorry folks, I just realized the oversight in the caption sentence:

For interrupts 0-12, some aliases of mip bits in sip may be read-only copies, as specified by the base Privileged Architecture.

To answer the original question of this thread, yes, bit SEIP is supposed to be read-only in sip, whether it is aliased from mip or from mvip. (And sip.STIP is also read-only when aliased from mip.)

I'll see about getting a clarification into the AIA document soon, including improvements suggested by @kdockser. The proposed new sentence is: "For interrupts 0-12, some aliases of mvip and mip bits in sip are read-only copies, as specified by the base Privileged Architecture." And I'll add text that more explicitly covers SEIP, STIP, and SSIP in sip.

[ic-nerd]

helleo, here, when mideleg.SEIP=0, mvien.SEIP=1, mvip.SEIP=1 (or mideleg.SEIP=1, mip.SEIP=1), I still have two questions:

1. Is sip.SEIP read-only？or determined by the read and write attributes of the SEIP bit of mip/mvip? For instance, mvip.SEIP/mip.SEIP is writable, and so is sip.SEIP？
2. In this case, the SEI interrupt is delegated into S-mode, what method should be used to clear the pending? "ecall?" Because sip.SEIP is read-only. It's not very clear here ”The SEI is delegated to S-mode, but cannot clear the pending by writing sip.SEIP. Why is that?“
   Thanks！

[jhauser-us]

The Privileged ISA document says, "If implemented, SEIP is read-only in sip, and is set and cleared by the execution environment, typically through a platform-specific interrupt controller."

SEIP is always read-only in sip. Either the value of sip.SEIP is a read-only zero, or it is a read-only copy of mip.SEIP, or it is a read-only copy of mvip.SEIP (bit 9 of mvip).

SEIP is read-only in sip because it is "normally" expected to be determined directly by an external interrupt controller. To change SEIP, you normally must change something at the external interrupt controller. Writing to sip won't accomplish that.

When sip.SEIP is a copy of mvip.SEIP, the M-level software is emulating the effects of an external interrupt controller.

[Steven-Li-Xiaogang]

@jhauser-us So S-level software can not clear it (mvip.SEIP) directly and has to issue ecall to clear from opensbi then return back

[jhauser-us]

Or M level can fully emulate an external interrupt controller for S level by trapping S-level's memory accesses to the emulated IC.