Are profiles guaranteed to be forwardly compatible with newer existing and future profiles from the same family?

[markdryan]

Will a binary compiled for the RVA22U64 profile, i.e., a binary restricted to using instructions included in the RVA22U64 mandatory base and the RVA22U64 mandatory extensions, be guaranteed to run successfully without modification on hardware that implements future RVAYYU64 profiles, e.g., RVA23U64, RVA24U64, RVA25U64?

Will a binary compiled for the RVA20U64 profile be guaranteed to run successfully without modification on all future RVAYYU64 hardware?

I can see that newer profiles aren't necessarily supersets of the older profiles, e.g., RVA20U64 supports Za128rs whereas RVA22U64 mandates Za64rs instead and RVA23U64 drops support for the RVA22U64 optional extensions Zkn and Zks. However, the existing older profiles do appear to be binary compatible with the newer ones as long as you stick to the mandatory base and the mandatory extensions. ( I'm assuming here that the change from Za128rs to Za64rs is an implementation detail and is unlikely to break binary compatibility in normal uses of LR/SC ).

I can't see this explicitly mentioned in the profiles documentation so wanted to be sure that existing profiles are intended to be forwardly compatible with all future profiles from the same family. If they are, would it be possible to add a statement about forward compatibility to the documentation?

[kasanovic]

The general intent is for future RVA profiles to retain backward compatibility with earlier profiles. Dropping an option does not break backward compatibility, as a portable binary must have used some form of discovery mechanism to make use of a non-mandatory option along with a fall-back path if the option was not present. Over longer time scales (decades) it may be necessary to deprecate instructions, so there is not a strict guarantee for all time. A more general statement along these lines would make sense in the profiles introduction and overview, and should be added when we aggregate all the standards into a single document tree.

[sorear]

RVA23S64 is not formally backward compatible with RVA20S64 and RVA22S64 since RVA20S64 and RVA22S64 require Svade, in other words, the earlier profiles affirmatively require that the Svadu option in RVA23S64 is not implemented. Practically speaking, supervisor software should be written to support either Svade or Svadu behavior, but from a formal perspective "address translations which hit a PTE with A=0 or D=0 cause a page fault" is as mandatory as any other requirement in RVA20S64.

In the past I've used this as an argument that RVA23S64 must require ADUE=0 unless the supervisor has opted in to ADUE=1 using the SBI or an equivalent mechanism, but currently I prefer to treat this as errata in RVA20S64 and RVA22S64: hardware may provide either Svade or Svadu, software must accept either. As I understand the intent, the memory ordering rules for PTE automatic update in the privileged ISA 1.11 were considered too imprecise to use, so RVA20S64 forbade hardware from implementing automatic update until a new specification could be developed. All other ratified bits in menvcfg and henvcfg exist for the purpose of matching the behavior of a host to non-portable behavior expected by a guest, and do not make sense to modify using SBI or equivalent mechanisms.

Do we have a procedure for errata in RVA20S64 and RVA22S64?

Do we consider RVA20S64 and RVA22S64 correct as written, and intentionally forward-incompatible with RVA23S64?

[tariqkurd-repo]

Isn't is the case that Svade behaviour is superceded by Svadu? Because Svadu simply means that the exception won't be taken and the A and D bits are maintained in hardware, so the software support becomes redundant. Is there some subtlety I'm missing here for the compatibility?

Also I think that RVA23 should say that the presence of Svadu means that Svade isn't implemented, as the two are mutually exclusive, and not additive.

[ved-rivos]

Also I think that RVA23 should say that the presence of Svadu means that Svade isn't implemented, as the two are mutually exclusive, and not additive.

Svadu does not mean Svade is not implemented. Svadu provides the controls to enable/disable hardware updating of A/D bits. An implementation must support Svade and may optionally support Svadu. When Svadu is supported, if HADE is 0 then hardware updating of A/D bits is not enabled and is enabled when it is 1. When hardware updating of A/D bits is not enabled then the Svade extension takes effect and when it is enabled the Svadu extension takes effect.

A hypervisor may switch to Svade behavior for VS mode even if Svadu is provided by the implementation to support use cases such as page table shadowing. When shadow page tables are in effect, the page fault exception trap handler on page faults caused by A/D bits in shadow page tables may emulate either Svade or Svadu for the shadowed page tables in the VM.

[kasanovic]

Closing as issue has been addressed.