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):

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?)

Greg