Can interrupt identity >63 cause a trap in non virtualized mode?

[zhuotianshu]

On page 61:

The RISC-V Privileged Architecture ensures that, when the value of mtopi is not zero, a trap is taken to M-mode for the interrupt indicated by fi eld IID if either the current privilege mode is M and mstatus.MIE is one, or the current privilege mode has less privilege than M-mode. The trap itself does not cause the value of mtopi to change.

The mtopi actually allows IID>63. But the Privilege spec says:

an interrupt traps to M-mode wheneverall of the following are true: (a) either the current privilege mode is M-mode and machine-level interrupts are enabled by the MIE bit of mstatus, or the current privilege mode has less privilege than M-mode; (b) matching bits in mip and mie are both one; and (c) if mideleg exists, the corresponding bit in mideleg is zero.

The mip and mie cannot be wider than 64, so why are they compliant?

[jhauser-us]

The value of mtopi.IID can be greater than 63 only with another extension, which might be a custom extension or a future standard one. By specifying field IID in mtopi as 12 bits wide, the AIA is pre-allocating space in mtopi for such an extension. But the current AIA does no more, itself supporting only values up to 63.

An extension that allows for interrupt numbers > 63 will need to specify what is missing, including modifying the existing rules for when a trap is taken.

Today, the expectation is that only custom extensions might use interrupt numbers greater than 63. But it's always possible that the RVIA may someday choose to ratify a new standard extension that does so.

[zhuotianshu]

@jhauser-us Understood. Thank you very much!