System Register XML
for Armv8.6
(2020-06)
30 June 2020
1. Introduction
This is the 2020-06 release
of the System Register XML for Armv8.6, describing:
-
The AArch64 and AArch32 views of the System registers
(including Debug, PMU, AMU, MPAM, Generic Timer, and GIC).
-
The AArch32 and AArch32 system control operations.
-
The memory-mapped Debug, CTI, PMU, AMU, MPAM, GIC, and Generic Timer registers.
The Proprietary Notice
gives details of the terms and conditions under which this package
is provided.
If you have comments on the content of this package, please send
them by e-mail to
support-aarchv8@arm.com.
Give:
- The title, "System Register XML for Armv8.6".
- The version, "2020-06".
- A concise explanation of your comments.
Please see the Documentation for
more information on the general structure of these descriptions.
2. Contents
3. Release notes
Change history
-
Architectural feature names used in the XML have been altered to a new format. See List of new vs old names. for a list of the old and new names.
-
The accessibility pseudocode for the following System instruction has been updated:
-
The accessibility pseudocode for the following registers has been updated:
-
AArch32: FPSCR, FPEXC, TRFCR.
-
AArch64: AMEVTYPER<n>_EL0, DBGBCR<n>_EL1, DBGBVR<n>_EL1, DBGWCR<n>_EL1, DBGWVR<n>_EL1, DBGDTRRX_EL0, DBGDTRTX_EL0, DBGDTR_EL0, ZCR_EL1.
-
In addition, in accessibility pseudocode for AArch64 registers, conditions that check ELUsingAArch32(ELx) when ELx is higher than the current Exception level, have this redundant check on ELUsingAArch32(ELx) removed. Redundant accessibility text for EDSCR.SDD handling has also been removed.
-
The architecture has been relaxed to permit the upper 8 bits of the ASID to be written 0 by the software when the context being invalidated only uses 8 bits. This applies to all the AArch64 TLBI maintenance instructions.
-
Extension to ERRDEVAFF Affinity fields to enable subsets of PEs at an affinity level.
-
Clarification that in the ERRGSR register, a record can choose not to expose the Valid bit through ERRGSR .
-
The architecture has been relaxed so that the address in FAR_ELx on an exception due to a tag check fault caused by a DC ZVA instruction is IMPLEMENTATION DEFINED as one of:
- FAR_ELx contains the lowest address that gave rise to the fault.
- FAR_ELx contains the address specified in the register argument of the instruction, as generated by MMU faults caused by DC ZVA.
-
Clarification of the behaviour of DC GVA and DC GZVA instructions in the ESR_ELx.CM field on a Data Abort.
-
Corrected field descriptions in EDPRCR and EDPRSR for when ARMv8.3-DoPD (FEAT_DoPD) is implemented.
-
In PMBSR_EL1, introduced new EC value and MSS for a buffer management event for an IMPLEMENTATION DEFINED reason.
-
Clarification of the priority of the HFGITR_EL2.ERET == 1 trap over the HCR_EL2.API == 0 trap.
-
The HCR_EL2.ATA field description incorrectly stated that its behavior is dependent on SCR_EL3.ATA. This is corrected to be consistent with the accessibility pseudocode in the System registers and instructions dependent on this bit.
-
ID_AA64MMFR2_EL1.NV updated to indicate optionality of ARMv8.3-NV (FEAT_NV) and ARMv8.4-NV (FEAT_NV2).
-
The GCR_EL1.Exclude field description is missing information about when the Allocation Tag value 0 is used. This is now clarified.
-
Clarification of the interaction between HCR_EL2.FWB and SCTLR_EL1.C.
-
Clarification that conditions for access to ExPD bits in TCR_ELx registers refer to Unprivileged access, not EL0 accesses.
-
The PMSICR_EL1.ECOUNT field description incorrectly stated that this field is RES1 when PMSIDR_EL1.ERnd is 0. The statement is now removed.
-
Restriction that the RAS common fault injection mechanism handles only errors that are explicitly supported at the node.
-
Clarification of requirements for upper bits of VA Range for VBAR_ELx.
-
Correction to state that HCR_EL2.TLOR trap is Non-secure only.
-
Corrected list of System instructions unallocated when Armv8.5-MemTag (FEAT_MTE) is not implemented.
-
The description of the ID_AA64ISAR0_EL1.AES field has been corrected to state that the presence of the AES instructions without the 64-bit PMULL instructions (value 0b0001) is not permitted.
-
Updated content for PMEVTYPER<n>.{NSH,SH} / PMCCFILTR_EL0.SH in Secure-only implementation with EL2.
-
The NRDY field descriptions in the following regsiters have been modified to correctly represent the behavior:
-
MSMON_CSU, MSMON_CSU_CAPTURE, MSMON_MBWU, MSMON_MBWU_CAPTURE, MSMON_MBWU_L, MSMON_MBWU_CAPTURE.
-
The MAIR_EL<n>.Attr<n> = 0b11110000 description has been clarified to include a condition on ARMv8.5-MemTag (FEAT_MTE).
-
The HCR_EL2.NV1 description incorrectly depends on the value of HCR_EL2.NV2. This has been corrected to remove that dependency.
-
The Purpose section of RNDRRS incorrectly described that reseeding happens at an IMPLEMENTATION DEFINED rate. This is corrected to state that the reseeding happens before the read of the random number.
-
The Configuration statements for ERRCRICRx, ERRERICRx, ERRFHICRx and ERRIRQSR external registers in debug have been clarified to state when the registers are implemented.
-
EDPFR.AMU now supports ARMv8.6-AMU (FEAT_AMUv1p1).
-
Added statement that ROMADDR is UNKNOWN when Valid == 0b00 to MDRAR_EL1.ROMADDR and DBGDRAR.ROMADDR.
-
Correction to DBGBCR<n>.BT field value 0b0010 description to change a condition on HCR_EL2.TGE from 0 to 1.
-
Correction to MPAMF_PRI_IDR.DSPRI_WD and INTPRI_WD fields to indicate the correct maximum
width of the MPAMCFG_PRI.DSPRI and INTPRI fields.
Known issues
All issues identified in the below list would be fixed in a future release.
-
The accessibility pseudocode of SCXTNUM_EL1 and the description of HCR_EL2.NV1 value 0b1
will be updated to add SCXTNUM_EL1 to the list of registers trapped to EL2..
-
Clarification of a number of MPAM registers.
-
The purpose in MPAMF_CCAP_IDR corrected to indicate that it provides information
about the MPAMPCFG_CMAX.CMAX field.
-
The description of MPAMF_CSUMON_IDR.CSU_RO is corrected to indicate it applies to
the MSMON_CSU monitor register.
-
The description of MPAMF_CSUMON_IDR.NUM_MON is corrected to indicate the number of
instances implemented and the maximum valid value.
-
SCTLR_ELx.ITFSB field descriptions do not fully define exception entry synchronisation
requirements for Tag Check Faults due to instructions executed before exception entry.
-
Corrections to the field value description in PMSCR_EL1.PCT, PMSCR_EL2.PCT, TRFCR_EL1.TS,
TRFCR_EL2.TS, and TRFCR.TS to remove HCR_EL2.{E2H, TGE} is {1, 1} from the list of
conditions when the Time stamp is 0, and for the TRFCR registers, add the conditions
that EL3 is using AAArch32, or EL2 is enabled in the curent Security state and using AArch32.
-
Correction to the field descriptions in MDCR_EL3.STE and SPME fields to say that the
fields have an Effective value of 1 if EL3 is not implemented and the Effective value of SCR_EL3.NS is 0.
-
The HCR_EL2.NV1 description incorrectly depends on the value of
HCR_EL2.NV2. This will be corected to remove that dependency.
-
Correction to the RESS and VA fields descriptions of DBGBVR<n>_EL1 and DBGWVR<n>_EL1
to indicate conditions when the RESS field is ignored, and the valid IMPLEMENTATION DEFINED
behavior when not ignored.
-
Clarification of the description in the Data Abort ISS of ESR_ELx.ISV when RAS is not implemented.
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:
-
Introduce field_rangesets to better capture a single field that is split across noncontiguous
bits (eg. DSPSR_EL0.IT is an 8-bit field using bits [15:10, 26, 25].
-
Such fields effectively appear as multiple fields today, but this would enable these
to be viewed as one. To preserve backwards compatibility, we propose to preserve this
for at least 6 months. The additional entries would have an is_duplicate == TRUE property.
-
For the register diagrams represented via reg_fieldset, there may be multiple entries
for the same split field. They would all point to the same is_duplicate == FALSE entry.
A concept of a label would be introduced to capture the text that is displayed in each
case.
-
Introduce a concept of field_array_indexes for field_array that allow field_array indices
to be discontinuous. This would also make the index of the array and fieldset explicity.
E.g HSTR_EL2.Tn, Bits [15, 13:5, 3:0] n = 15, 13:5, 3:0. This would not have a backward
compatibility option.
-
We are looking at representation of reset information using an ASL expression in certain cases.
-
We are looking at separating accessors (instructions/external accesses) from registers. This
is likely to impact "Index by Encoding", "External registers by offset" and may introduce
separate pages for instructions/accessors vs. the registers. This may impact the schema and
the presentation of the content.
-
Some changes to register names may be introduced and there may be changes to the number
of registers or names. The instructions accessing registers would be unchanged - preserving
the architecture intent.
-
Register accesses that always look like simple reads or writes will
be extended to have some ASL expressions. Where register accesses cause additional side
effects, ASL functions that describe these effects will be added. Currently these details
are only expressed in text.
-
We are considering the obsoletion of some DTD elements based on usage and analysis.
-
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.
-
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.
4. Documentation
General
A description within the XML contains the following sections:
- Purpose
-
A short description of the purpose of the register in the
Armv8 Architecture.
- Configuration
-
How the register is architecturally mapped onto another System
register or a memory-mapped register. If the configuration of
the PE affects the implementation of the register, then
information about this is also included here.
- Attributes
-
The size of the register. For registers where the layouts of
the fields differ based on configuration, or other state
within the PE, this section also summarizes the different
layouts.
- Field descriptions
-
The register diagram, and a description of the behavior of
each field within the register.
Memory-mapped registers
A memory-mapped register description also contains the following
sections:
- Accessing the ...
-
The address or offset of the register in the memory map, and
the accessibility.
System registers
A System register description also contains an "Accessing the
..." section, that includes:
-
The assembler syntax for the instructions used to access the
register, and how the instruction is encoded.
-
Pseudocode that describes the execution of all instructions
used to access the register, including information about
traps and enables that apply upon that access.
-
For some System registers, additional text is provided which
gives extra information regarding the access to the
register.
-
The accessibility pseudocode for a register assumes that
that register is implemented and that all features which
affects its accesses are implemented. In most cases, the
behavior upon access to a register is determined in part or
in whole by the Exception level at which it is accessed.