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 https://github.com/riscv/riscv-smmtt/blob/3b03fb0a0ee88fc077006cb8e77d3ae3ffe67093/chapter7.adoc?plain=1#L201-L203 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 https://github.com/riscv/riscv-smmtt/blob/3b03fb0a0ee88fc077006cb8e77d3ae3ffe67093/chapter7.adoc?plain=1#L138-L139 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 https://github.com/riscv/riscv-smmtt/pull/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)