Re: Disabling and re-enabling extensions

Greg Favor

On Thu, Sep 10, 2020 at 6:47 AM mark <markhimelstein@...> wrote:
Is there a checklist of requirements for priv specifications?
if not should there be?

I'm not sure, off-hand, if there is a many item list to be created or not.  (Andrew probably has better thoughts on this.)  But on the particular topic of this email thread, my leaning would be to say (to all extension TG's) the following:

- An extension spec must be "complete", i.e. it fully specifies all behaviors, including for all corner cases.

- It is alright for some behaviors to be specified as UNSPECIFIED, but it is preferable for specific behavior(s) to be specified - unless this would be burdensome on a worthwhile subset of reasonable implementations.  Further, in the latter case, specifying a bounded set of two allowed behaviors is acceptable if that would be of value to software (or compliance testing or SAIL modeling) instead of just specifying UNSPECIFIED.

Regarding the specific question of the H-specific state when disabling then re-enabling the H-extension (or more generally disabling then re-enabling any Priv extension), I suspect the following would be a reasonable specific behavior to specify (in the spirit of the preceding general philosophy):

When misa.H is cleared, the values of all state that become either inaccessible or masked (e.g. treated as _effectively_ a fixed value) are preserved such that these values become visible again when misa.H is set and this state becomes accessible and unmasked.

In other words, flop state is left untouched and any values that must now _appear_ as a fixed value are implemented via physical masking of the flop value (instead of changing the flop state).

Although I would try and argue - for the H-extension - that this provides no value to software (in the seemingly rare cases of this scenario happening).  In which case specifying UNSPECIFIED would seem suitable for the sake of avoiding unnecessary over-specification of behavior.

Lastly, it would seem desirable that all Priv extensions should, by default, have the same specification for what happens when the extension is disabled and then re-enabled.  In which case my own leaning would be towards the "UNSPECIFIED" option as the general default across all priv arch extensions.  Or otherwise towards the "preserve underlying state" option if Andrew or others felt this as being more appropriate.  (Or is there a better default option?)


Join { to automatically receive all group messages.