Re: Smstateen for Zcmt
|
Greg Favor
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
|
|
|