The smclicshv extension naming (i.e. sm*) suggests it only has M-mode features but it affects S-mode and has one S-mode CSR bit

[james-ball-qualcomm]

The smclicshv extension naming (i.e. sm*) suggests it only has M-mode features. Does it have S-mode features too? I ask because the smclicshv chapter uses the 'x' prefix notation instead of 'm'. What gives?

[jb-brelot-nxp]

From my side this extension is affecting all mode supported by the CLIC.

If CLIC is supporting only M mode, then this extension will affect only M registers
If CLIC is supporting M and S mode, then this extension will affect M and S mode.

As soon as you get Selective Hardware vectoring supported on M mode, the cost to support it for S is for free.
So x prefix is the good one from my side.

Maybe I forget some aspects. We can discuss this tonight.

[christian-herber-nxp]

i think there is no precedent for an x prefix in an extension.
the normal thing to do is to have a smclicshv and a ssclicshv.
However, here we do not want them to be selectable individually.
So if smclicshv and sslic are supported, ssclicshv is mandatory. Otherwise, ssclicshv is forbidden.

[james-ball-qualcomm]

Precedent in Priv ISA manual:

Chapter 5. "Smcsrind/Sscsrind" Indirect CSR Access, Version 1.0.0
5.1. Introduction
Smcsrind/Sscsrind is an ISA extension that extends the indirect CSR access mechanism originally
defined as part of the Smaia/Ssaia extensions, in order to make it available for use by other extensions
without creating an unnecessary dependence on Smaia/Ssaia.
This extension confers two benefits:

[james-ball-qualcomm]

Another:

Chapter 4. "Smstateen/Ssstateen" Extensions, Version 1.0.0