Re: Smstateen for Zcmt


Tariq Kurd
 

<gmail web has a shortcut to send an email which I accidentally hit>

Thanks for the very helpful email - I think this is the first time that a new state enable has been added since Smstateen was ratified.
The reason that it's required is that there's a new CSR: JVT, which must not be used as a covert channel.
My intention was only to disable this CSR, and not to disable any of the new instructions from any of the Zc extensions.
The question which arose was prompted by this text from the Smstateen spec:

"In some cases, the bits of the stateen CSRs will have a dual purpose as enables for the ISA
extensions that introduce the controlled state."

And so the question is whether the instructions are also disabled.

Can we clarify this?

Tariq


On Mon, 16 May 2022 at 17:59, Tariq Kurd <tariq.kurd@...> wrote:
HI Greg,

Thanks for the very helpful email - I think this is the first time that a new state enable has been added since Smstateen was ratified.
The reason that it's required is that there's a new CSR: JVT, which must not be used as a covert channel.
My intention was only to disable this CSR, and not to disable any of the new instructions from any of the Zc extensions.
the question which arose was prompted by this text from the Smstateen spec:




On Mon, 16 May 2022 at 17:36, Greg Favor <gfavor@...> wrote:
Tariq,

Thanks for enquiring about new ISA extension coordination with the Smstateen extension that was ratified last year.

The first thing to note is that the primary purpose of and motivation for Smstateen is to close off covert communication channels created by new extensions that add new arch state that needs to be context switched (but may not be context switched by an unaware OS or hypervisor).  (A secondary usage of Smstateen is for rare cases of extensions that are not backward compatible and need to be disablable for backward compatibility.)  This extension is not intended to provide a general mechanism for disabling arch extensions.  Many extensions don't need such and one that does would define its own appropriate mechanism based on the nature of the extension.  (Smepmp, for example, implicitly provides practical backward compatibility by how it defines the semantics of the new CSR bits that it introduces - such that new or modified functionality only becomes active when explicitly enabled by software.)

The second thing to note is that Smstateen, as ratified last year, comprehended the few other extensions that were ratified last year that needed Smstateen support.  Going forward, a new ISA extension that fits the preceding primary and secondary Smstateen use cases should specify any new bit(s) it adds to the *stateenX CSRs.  Then, once it is ratified, this should be moved into the Smstateen chapter that will exist in the Priv spec (when the Smstateen extension itself is merged into the Priv spec - tbd whether before or after Priv conversion to adoc).  The post-ratified ISA extension spec should retain a short mention of and cross reference to the added Smstateen bit(s).

This will put all the new arch functionality introduced by a new ISA extension into one spec document for use during TG reviews, Arch Review, Tech Chairs/TSC/BoD votes, and public review.  Then the added Smstateen detailed functionality can be moved into the Smstateen chapter after ratification.

Regarding Zcmt in particular (which is due to be ratified this year I believe), it seems like adding Smstateen functionality might be necessary only if Zcmt breaks backward compatibility by redefining existing defined opcodes.  I don't remember if that applies here.  (It might be worth considering whether that is truly necessary since such a Zcmt extension would be incompatible with the existing arch extension that it conflicts with, and the question would then be whether some implementations are expected to implement both conflicting extensions - and hence need an extension enable.  Otherwise extension discovery via the new RV "unified low-level discovery" method would inform software as to whether Zcmt is implemented and the conflicting extension is not implemented.)

Greg


On Mon, May 16, 2022 at 6:58 AM Tariq Kurd via lists.riscv.org <tariq.kurd=codasip.com@...> wrote:
In this particular case, the issue is that the Smstateen spec comes later, and hasn't been addressed yet. I believe it's out of scope for Zc, it is simply noted that new state (the JVT CSR) is added so a state enable is required.
As SiLabs are actually implementing Zc right now, they are asking sensible questions about it, so we need to complete this part of the Smstateen spec.

Greg - any input on this would be appreciated.

Tariq

On Mon, 16 May 2022 at 15:47, Mark Himelstein <markhimelstein@...> wrote:
Please talk with Greg and decide.

This is why we have cross group involvement. When a spec is ratified and a TG is disbanded, the Committee has ultimate responsibility.

I have a question though. Is there learning we need to have from this? If the issue wasn't raised how would we have found this? Do we need a list of standard dependencies/interactions?

Thanks
Mark

On Mon, May 16, 2022 at 5:55 AM Tariq Kurd via lists.riscv.org <tariq.kurd=codasip.com@...> wrote:
Hi,

We have a question on github about the implementation of smstateen for Zcmt (table jump).
There's the JVT CSR which needs a state enable. The question is whether there is also a state-enable for the ISA extension.


Who is responsible for the Zcmt Smstateen spec?

Thanks

Tariq

--

Tariq Kurd | Lead CPU Architect | Codasip UK Design Centre | www.codasip.com



--

Tariq Kurd | Lead CPU Architect | Codasip UK Design Centre | www.codasip.com



--

Tariq Kurd | Lead CPU Architect | Codasip UK Design Centre | www.codasip.com



--

Tariq Kurd | Lead CPU Architect | Codasip UK Design Centre | www.codasip.com

Join tech-privileged@lists.riscv.org to automatically receive all group messages.