Release notes for System Registers for Armv8.6-A (2020-03)

Change history

  • The accessibility pseudocode for the following System instructions has been updated:
    • AArch64: TLBI VALE1.
    • AArch32: BPIALLIS, CFPRCTX, CPPRCTX, DCCSW, DVPRCTX, ICIALLUIS, ITLBIMVA, TLBIIPAS2IS, TLBIIPAS2L, TLBIIPAS2LIS.
  • The accessibility pseudocode for the following registers has been updated:
    • AArch64: AMEVCNTOFF0<n>_EL2, AMEVCNTOFF1<n>_EL2, CNTPCT_EL0, CNTPCTSS_EL0, CPACR_EL1, CNTHVS_CTL_EL2, CNTHVS_CVAL_EL2, CNTHVS_TVAL_EL2,
      CNTHV_CTL_EL2, CNTHV_CVAL_EL2, CNTHV_TVAL_EL2, CNTVCTSS_EL0, CNTVCT_EL0, CNTV_CTL_EL0, CNTV_CVAL_EL0, CNTV_TVAL_EL0.
    • AArch32: AMEVCNTR0<n>, CNTPCT, CNTPCTSS, CNTHVS_CTL, CNTHVS_CVAL, CNTHVS_TVAL, CNTHV_CTL, CNTHV_CVAL, CNTHV_TVAL, CNTVCT, CNTVCTSS,
      CNTV_CTL, CNTV_CVAL, CNTP_TVAL, FPSID
  • Relaxation for corrected-only nodes in ERR<n>FR.
  • ARMv8.4-CondM, ARMv8.4-LSE, and ARMv8.4-RCPC features relaxed to be permitted from Armv8.2.
  • Incorrect AArch32 condition removed from M[4] fields in the SPSR registers.
  • Clarifying the identification mechanism for ARMv8.2-EVT.
  • Correction to DC GVA instruction description.
  • Tagged Normal memory type clarification added to HCR_EL2.FWB.
  • ERR<n>STATUS field access clarification.
  • Implementations that implement ARMv8.5-E0PD must implement ARMv8.0-CSV3. This is a tightening of the architecture rules.
  • All references to "context" are clarified to be the "target execution context" in the descriptions of the following System instructions:
    • AArch64: CFP RCTX, CPP RCTX, and DVP RCTX.
    • AArch32: CFPRCTX, CPPRCTX, and DVPRCTX.
  • Clarification of granule size values when ARMv8.2-LPA not implemented.
  • Clarification of permitted value of ID_AA64MMFR0_EL1.SNSMem
  • Invalid field values removed from description of PAR and PAR_EL1 registers.
  • Clarification of the debug target Exception level in MDCR_EL2 and HDCR.
  • The list of permitted values of ID_AA64ISAR1_EL1.DPB has been corrected.
  • Many simple clarifications and corrections are also present, but are too small to be listed here.

Known issues

All issues identified in the below list would be fixed in a future release.

  • Many AArch32 registers have a statement that indicate access to the register is UNKNOWN if AArch32 is not supported. This statement is nonsensical and will be removed in the next release.
  • The description of the CM field in ESR_EL1, ESR_EL2, and ESR_EL3 on a Data Abort does not call out the behaviour for the DC GVA and DC GZVA instructions added by ARMv8.5-MemTag.
  • The text in HCR_EL2.ATA bit incorrectly states that its behaviour is dependent on SCR_EL3.ATA. This is inconsistent with the accessibility pseudocode in the System registers and instructions dependent on this bit.
  • The optionality of ARMv8.3-NV and ARMv8.4-NV is not reflected in the ID_AA64MMFR2_EL1.NV description. This description will be updated in the next release.
  • The GCR_EL1.Exclude field description is missing information about when the Allocation Tag value 0 is used. This will be corrected in the next release.
  • In the AArch32 FPSCR register description, the accessibility from VMSR and VMRS instruction incorrectly indicates UNDEFINED behavior for EL0 accesseses. This is however correctly captured in the VMSR and VMRS instruction pseudocode. This is now corrected.
  • The use of 'EL0 accesses' in the TCR_ELx.E0PDn descriptions causes some confusion. This will be corrected to 'unprivileged accesses' in the next release.
  • The PMSICR_EL1.ECOUNT field description incorrectly mentions that this field is RES1 when PMSIDR_EL1.ERnd is 0. This text will be removed in the next release.

Potential upcoming changes

We are looking in improvements to the information that is provided in the XML. In some cases these changes may impact users. Here is a list of areas where we may make changes in a future release:

  • We are looking at defining a standard for naming features across all architecture versions. In the next release, all feature names would be updated to the new standard.
  • The instruction encoding tables currently present values as binary values, with the prefix "0b". We are considering whether these values are better represented in a syntax compatible with pseudocode.
  • How the read/write behaviors in register fields are identified is being investigated.
  • The reset information in the 'Configuration' section of some register descriptions have incorrect information, and must not be relied upon. Please refer to the field descriptions for the correct reset information. The information in the 'Configuration' section will be removed in a future release.