Software wants to know precisely how an execution environment behaves. Allowing some instructions to be implemented as illegal-exception trap warrants a set of new extensions to describe all possible implementations.
It would be clearer to split ACE extension into at least two extensions:
- Setup of ACE state (ace.import and friends)
- Operations with ACE state (ace.exec and friends)
Execution environments could choose which extensions to implement. Hardware (the EE for M-mode) could implement just 2, and M-mode would implement both 1 and 2 for lower privileges. Extension 1 would be implemented in software and extension 2 accelerated by hardware.
We could also define an extension 3 for the Manual setup of ACE state (ace.mv and friends), but that would require specification of ACE state that is currently micro-architectural.
e.g. To implement ace.import with ace.mv in M-mode, software needs to know how ace.exec expects the (meta)data for the CR to be laid out, so that it can correctly set up the architectural state after unsealing the SCC in software.
What is the goal behind architecting partial ACE implementations?
(If a vendor that doesn't open their M-mode to others wants to do the trappable ACE instruction, they can do that even with the current specification, since lower privilege levels don't care how ACE is implemented, only that it behaves according to specification.
Just implement partial ACE acceleration in hardware, and wire it so that S-mode and below can't tell a difference.
Note that even ace.exec can be fully implemented in M-mode software while providing a perfect ACE implementation to lower privilege levels.)
Software wants to know precisely how an execution environment behaves. Allowing some instructions to be implemented as illegal-exception trap warrants a set of new extensions to describe all possible implementations.
It would be clearer to split ACE extension into at least two extensions:
Execution environments could choose which extensions to implement. Hardware (the EE for M-mode) could implement just 2, and M-mode would implement both 1 and 2 for lower privileges. Extension 1 would be implemented in software and extension 2 accelerated by hardware.
We could also define an extension 3 for the Manual setup of ACE state (
ace.mvand friends), but that would require specification of ACE state that is currently micro-architectural.e.g. To implement
ace.importwithace.mvin M-mode, software needs to know howace.execexpects the (meta)data for the CR to be laid out, so that it can correctly set up the architectural state after unsealing the SCC in software.What is the goal behind architecting partial ACE implementations?
(If a vendor that doesn't open their M-mode to others wants to do the trappable ACE instruction, they can do that even with the current specification, since lower privilege levels don't care how ACE is implemented, only that it behaves according to specification.
Just implement partial ACE acceleration in hardware, and wire it so that S-mode and below can't tell a difference.
Note that even
ace.execcan be fully implemented in M-mode software while providing a perfect ACE implementation to lower privilege levels.)