You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Control Transfer Records (CTR) ISA extension contains a significant amount of state (100s of CSRs). Implementations are not required to retain the values of CTR state across clock-gated low-power state(s); instead, CTR CSRs may contain a legal but unspecified value.
For implementations that do not preserve CTR state, ACPI should provide indication to supervisor software. In that case, software should do the following:
On low-power entry, save xctrcontrol and sctrstatus values. Optionally, save CTR entry state.
On low-power exit, restore saved xctrcontrol and sctrstatus values. Then execute CTRCLEAR, unless restoring CTR entry state for the max supported xctrcontrol.DEPTH value. Optionally, restore saved CTR entry state.
I presume the best approach for this will be to assign an Arch Context Lost Flag (bit 1?) for CTR state. I am not sure whether the software guidance above belongs in the CTR spec or the FFH spec. I'm also unclear where (or whether?) to indicate to implementations that this option to not preserve CTR state exists. I don't see any such indication for the hart timer in the priv spec.
CTR is still in the approval process, currently in ARC review. I hope to get this issue closed once CTR is ratification-ready.
The text was updated successfully, but these errors were encountered:
The Control Transfer Records (CTR) ISA extension contains a significant amount of state (100s of CSRs). Implementations are not required to retain the values of CTR state across clock-gated low-power state(s); instead, CTR CSRs may contain a legal but unspecified value.
For implementations that do not preserve CTR state, ACPI should provide indication to supervisor software. In that case, software should do the following:
I presume the best approach for this will be to assign an Arch Context Lost Flag (bit 1?) for CTR state. I am not sure whether the software guidance above belongs in the CTR spec or the FFH spec. I'm also unclear where (or whether?) to indicate to implementations that this option to not preserve CTR state exists. I don't see any such indication for the hart timer in the priv spec.
CTR is still in the approval process, currently in ARC review. I hope to get this issue closed once CTR is ratification-ready.
The text was updated successfully, but these errors were encountered: