Smsdia clarifications

[IMG-S-Hopton]

Hi,

A couple of questions relating to Chapter 7 (Smsdia) please.

1
With respect to the Supervisor Domain External Interrupt (SDEI); The current text does not contain where in the priority order this is expected to be seen - am I right in thinking that since this is a machine-mode only interrupt which cannot be delegated, it comes before SEI?

Multiple simultaneous interrupts destined for different privilege modes are handled in decreasing order of
destined privilege mode. Multiple simultaneous interrupts destined for the same privilege mode are handled in the
following decreasing priority order: MEI, MSI, MTI, SDEI, SEI, SSI, STI, LCOFI.

2

riscv-smmtt/chapter7.adoc

Lines 201 to 203 in 3b03fb0

	The `msdeie` is a MXLEN-bit read-write register, formatted for MXLEN=64 as shown
	in <<MSDEIE>>. When MXLEN=32, `msdeieh` is a 32-bit read-only register which
	aliases bits 63:32 of `msdeie`. When MXLEN=64, `msdeieh` does not exist.

msdeie is a read-write register, but msdeieh is mentioned to be read-only; am I correct in thinking this is a copy paste error?

3
https://github.com/riscv/riscv-smmtt/blob/3b03fb0a0ee88fc077006cb8e77d3ae3ffe67093/chapter7.adoc?plain=1#L40C1-L55C5
The "Supervisor Domain Interrupt Assignment" diagram references an SD-0 APLIC/IMSIC, but msdcfg does not allow 0 to be used as a selection for an IMSIC/APLIC. Is this intentional?

4

riscv-smmtt/chapter7.adoc

Lines 138 to 139 in 3b03fb0

	* When `Ssaia` extension is implemented, then the implementation behaves as if
	`mstateen0` bits 60, 59, and 58 were all 0.

SDICN being 0 refers to acting as mstateen0 bits 60/59/58 being 0; the AIA spec specifically states that this does not affect M-mode accesses.

As always, the state-enable CSRs do not affect the accessibility of any state when in M-mode, only in less privileged modes.

Am I right in thinking that the intended behaviour in all modes including M is actually to be the same as if there is no IMSIC connected (e.g. sireg access while siselect is in the IMSIC range raises an illegal instruction exception)?

When siselect is a number in a reserved range (currently 0x00–0x2F, 0x40–0x6F, or a number above 0xFF not designated for custom use), or in the range 0x70–0xFF when there is no IMSIC, attempts to access sireg should preferably raise an illegal instruction exception (unless executing in a virtual machine, covered in the next section).

Thanks! :)

Selina

[ved-rivos]

am I right in thinking that since this is a machine-mode only interrupt which cannot be delegated, it comes before SEI?

Thats right.

msdeie is a read-write register, but msdeieh is mentioned to be read-only;

Should be read-write.

The "Supervisor Domain Interrupt Assignment" diagram references an SD-0 APLIC/IMSIC, but msdcfg does not allow 0 to be used as a selection for an IMSIC/APLIC.

The IMSIC/APLIC selection is done by SDICN and not SDID.

Am I right in thinking that the intended behaviour in all modes including M is actually to be the same as if there is no IMSIC connected

The behavior only applies to privilege level less than M.

Updates made in #17

[IMG-S-Hopton]

Thanks :)

The behavior only applies to privilege level less than M.

So when SDICN is 0 and siselect points at IMSIC CSRs, which SD IMSIC is read by an M-mode access to sireg?

[ved-rivos]

You are right. I somehow misread the question as being related to stateen. Let me reword the quoted sentence to be more clear.

[ved-rivos]

The PR has been further updated to address these issues. Please take a look.

[IMG-S-Hopton]

Looks good - thank you! :)

[rsahita]

merged PR so closing issue (thanks @IMG-S-Hopton, @ved-rivos)