Vectored xTVEC/xTCC mode address may need checking

[tariqkurd-repo]

When programming xTVEC/xTCC the core does a representability check with the final legalised write value (specifically after legalising the MODE field).

However, when in vectored interrupt mode, the handler address is MTCC.address+4*CAUSE.
Standard interrupt numbers go up to 11, but platform defined ones can have higher numbers.
What do we do about ensuring that the resulting cap with the updated address is representable? Is there any realistic danger that it could be unrepresentable?

I'd prefer not to do a CSetAddr on the address after knowing the interrupt cause, I think it's more useful to do an improved check on writing, e.g. bounds of the maximum range of vectored addresses.

[jrtc27]

Morello does a representability check there

[jrtc27]

(CapSetValue is their function that does a CSetAddr, due to their awful nomenclature around the address)

[jrtc27]

Of course, depending on the number of interrupt sources you have, and what XLEN is, you may know that you can never go unrepresentable. You can surely specialise the representability check based on bounding how far out of bounds you could possibly be, too.

[tariqkurd-repo]

interesting, thanks. I guess either a representability or bounds check on write covers the case.