13 Attribute Transformation

Chapter 13 Attribute Transformation The Arm architecture supports a set of attributes that accompanies each external access that is made by a PE. These attributes map onto attributes carried by the interconnect in an interconnect-specific manner. The SMMU supports a set of attributes that is identical to that supported by the PE. These attributes govern the behavior of each client transaction and are presented from the SMMU to the memory system. The interconnect from the client device might also present attributes to the SMMU. This section describes how the attributes output with a transaction are determined from the SMMU configuration and the attributes supplied with the transaction on input. To avoid interconnect-specific language, this section uses attribute terminology and concepts as defined in the Arm Architecture Reference Manual [2]. The mapping of these attributes onto interconnect implementations that support a subset of the attributes is IMPLEMENTATION DEFINED. This section covers the attributes that are applied in the four conditions under which a transaction can pass through an SMMU: 1. Global bypass. The SMMU is disabled (SMMU_(S_)CR0.SMMUEN == 0). 2. STE bypass. The SMMU is enabled but all stages of translation are disabled by an STE. 3. Normal translation flow. An STE configures one or more stages of translation. 4. PCIe ATS Translated. A device requests a ‘pre-translation’, caches the result, and subsequently presents a transaction with an address that has been translated but has not had SMMU attributes applied. This section additionally covers accesses that originate from the SMMU, such as fetching configuration or walking translation tables. Depending on the path taken, attributes might be overridden or modified by SMMU configuration registers, STE fields or translation table entries. Some of the attributes are used when checking access permissions in translation table entries, others are provided for the memory system. At the highest level, the attribute determination for the normal translation flow is: ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1071

Chapter 13. Attribute Transformation 1. Input attributes are obtained from the incoming transaction and any attributes that are not provided are generated from constant default values. 2. The STE might then override incoming attributes for a specific stream. 3. The stage 1 and stage 2 translation table permissions are checked against the attributes determined from the previous step, where a stage is enabled. 4. If stage 1 is enabled, the stage 1 translation table attributes replace any input and STE override values. 5. If stage 2 is enabled, the stage 2 translation table attributes are combined with the stage 1 attributes if stage 1 is enabled, or combined with the overridden input attributes if stage 1 is not enabled. 6. The attribute is output with the translated transaction. ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1072

Chapter 13. Attribute Transformation 13.1. SMMU handling of attributes 13.1 SMMU handling of attributes 13.1.1 Attribute definitions A transaction has the attributes that are defined by the Arm architecture [2]: Attribute Shorthand Values Memory Type MT Normal i{WB, WT, NC}-o{WB, WT, NC} – generally Normal, Device-{GRE, nGRE, nGnRE, nGnRnE} – generally any-Device. Shareability SH Non-shareable (NSH),Inner shareable (ISH), Outer shareable (OSH) Note: Device types and Normal iNC-oNC are considered to be OSH Read Allocation hint RA Inner read allocate/no-allocate, Outer read allocate/no-allocate Write Allocation hint WA Inner write allocate/no-allocate, Outer write allocate/no-allocate Transient hint TR Inner transient/non-transient, Outer transient/non-transient Read/Write R/W Read, Write Inst/Data INST Instruction, Data Privilege PRIV Privileged/Unprivileged Non-secure NS Secure/Realm, Non-secure Key: • i = Inner, • o = Outer, • WB = Write-Back cacheable, • WT = Write-Through cacheable, • NC = Non-Cacheable, In this specification, a Normal memory type is expressed as: • iNC-oNC, or • i{ NC, {WB, WT}/[n]RA[n]WA[n]TR }-o{ NC, {WB, WT}/[n]RA[n]WA[n]TR }-{NSH,ISH,OSH} (Syntax: {a,b} = Choose one of a or b, [x] = x is optional.) This means that: • Normal-iWB/RAnWATR-oNC-ISH: – Is Inner writeback cacheable/Read-Allocate/no-Write-Allocate/transient, outer non-cacheable inner-shareable. – The (outer) NC type has no RA/WA or TR attributes. • Normal-iWB/RAWAnTR-oWB/RAWAnTR-OSH: – Is inner/outer writeback read/write allocate non-transient, outer-shareable. • Normal-iNC-oNC – Is architecturally non-cacheable, always OSH – NC has no RA/WA or TR attributes. ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1073

Chapter 13. Attribute Transformation 13.1. SMMU handling of attributes Note: System shareable is an AMBA interconnect term and is not used in this specification. Device memory is OSH according to the Arm architecture, but the AMBA interconnect Device type is System shareable. Similarly, a PE Normal-iNC-oNC attribute becomes Non-Cacheable System shareable in AMBA interconnect. Armv8-A memory attribute terminology is used in this specification. While some interconnects might support an IMPLEMENTATION DEFINED subset of these attributes, R/W is mandatory. The R/W, INST and PRIV attributes are used to check transaction permissions against the read/write and execute access permissions returned by the translation process. Some memory systems might also use INST, PRIV, RA, WA and TR attributes to influence cache allocation or prioritization policies but such usage is outside the scope of this specification. Some interconnects support atomic transactions. These are treated as performing both a data read and a write for permission checking purposes independent of STE.INSTCFG. For Event records generated due to atomic accesses: • In the event of a permission fault due to having write access but not read access, including the case where a descriptor is writable-clean, the value of the F_PERMISSION event’s RnW field is: – SMMUV3.0: IMPLEMENTATION DEFINED. – SMMUv3.1 and later: 1. • Note: In the event of a permission fault in response to not having write access, or having no access, the F_PERMISSION event is recorded with RnW == 0. • For all other causes that trigger F_PERMISSION, and for all other event types, RnW == 0. • For the purposes of setting the RnW, DirtyBit and Overlay bits in an F_PERMISSION record, the SMMU follows the permissions checks priority order where write permission is checked before read permission. When the SMMU supports Secure state, the output NS attribute is used by the memory system to distinguish between Secure PA space and Non-secure PA space. At stage 1, distinction between Secure and Non-secure addresses is used to check against SMMU_S_CR0.SIF. The access permission attributes of an incoming transaction are only used by the SMMU to enforce access permissions against the permissions determined by translation table descriptors and SMMU_S_CR0.SIF. They do not interact with the memory type in any way. Note: In AArch32 state, a PE is permitted to raise a Permission fault when an instruction fetch is made to Device memory and execute-never is not set. The SMMU does not raise a Permission fault in this case, and the output attribute remains Device. An access is permitted if the permission checks succeed, regardless of the final memory type. 13.1.2 Attribute support The SMMU defines behavior for all architected attributes. However, where an interconnect from the SMMU to the memory system supports only a subset of these attributes, the SMMU is not required to generate attributes that it does not use. With the exception of R/W, INST, and PRIV all configuration fields that affect unused attributes are IGNORED. When SMMU_S_IDR1.SECURE_IMPL == 1: • Override fields that are associated with the input NS attribute might be supported. • Any transaction that belongs to a Non-secure stream targets the Non-secure PA space. When SMMU_S_IDR1.SECURE_IMPL == 0: • Override fields that are associated with the input NS attribute are not supported. • Where supported by the memory system, all transactions target the Non-secure PA space. If an interconnect supports attributes but does not differentiate inner and outer in the same way as the architecture, the mapping onto the architecturally-defined set of attributes is IMPLEMENTATION DEFINED. ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1074

Chapter 13. Attribute Transformation 13.1. SMMU handling of attributes In some implementations, a client device might request translation services from an SMMU and later perform transactions separately, based on the translations and attributes determined by the SMMU. The behavior of the client device transactions with respect to attributes presented to the system are outside the scope of the SMMU architecture. Where such a client device does not support certain memory types or attributes that are returned by the SMMU translation process, behavior on accesses with these memory types is defined by the device implementation. However, the page permission protection model of the SMMU translations must always be fully observed. Note: For example, a client device must never use a read-only translation to issue a write transaction into the system. If a client device does not support a particular memory type, a valid behavior might be to alter the type in an architecturally-safe manner. This could be strengthening a Device-GRE access to a Device-nGnRnE access. If this is not possible, another valid behavior might be for the client device to abort the access in a client device-specific manner. Note: A composite device that contains an SMMU, such as an intelligent accelerator, is conceptually identical to a client device making requests of an external SMMU. The SMMU makes its own accesses to memory, for example to fetch configuration or perform translation table walks. Each access has a memory type and attributes that are configured using SMMU registers or structure fields. Where an SMMU and the memory system support only a subset of memory types, and where access to an unsupported type can be reported to the SMMU, the SMMU will record an external abort for the cause of the access in question in the architected manner. If such an access is instigated by an incoming transaction, the transaction will be terminated with an abort. A fetch from unsupported memory types generates the following fault and errors: • STE: F_STE_FETCH • CD: F_CD_FETCH • Command queue read entry: GERROR.CMDQ_ERR and Command queue CERROR_ABT • Event queue access: GERROR.EVENTQ_ABT_ERR • PRI queue access: GERROR.PRIQ_ABT_ERR • MSIs: GERROR.MSI_*ABT_ERR • Translation table walk: F_WALK_EABT Arm strongly recommends that an SMMU supports all architected access types (for both its own structure accesses and for client transactions) so that it is compatible with generic driver software. The SMMU considers all incoming writes to be Data, even if the client device marks the incoming write as Instruction. This is done on input, prior to any translation table permission checks. In addition, STE.INSTCFG and SMMU(S_)GBPA.INSTCFG can only change the instruction/data marking of reads. If an implementation provides INST and PRIV as output attributes to the memory system, then: • SMMU-originated accesses are always represented as Data, Privileged. This includes: – All reads that originate from the SMMU, for example a structure fetch. – All SMMU writes of output queue data and MSIs. • For client-originated transactions the following applies: – For SMMUv3.3 and earlier, the INST attribute reflects the output of the INSTCFG field for reads and is fixed as Data for writes. The PRIV attribute reflects the output of the PRIVCFG field. – For SMMUv3.4 and later the attributes are always Data, Privileged. 13.1.3 Default input attributes Where the SMMU is not supplied with an attribute because the interconnect between the client device and SMMU does not have the ability to convey it, the SMMU constructs a default input value: ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1075

Chapter 13. Attribute Transformation 13.1. SMMU handling of attributes Attribute Input generated as: MT Normal iWB-oWB SH NSH RA Allocate WA Allocate TR Non-transient INST Data PRIV Unprivileged NS Non-secure These values are used when any configuration path is set to ‘Use incoming’ attribute, but the attribute is not supplied. For example, if the incoming attributes are Normal-iNC-oNC or any-Device and MTCFG/MemAttr override this to Normal-iWB-oWB, but ALLOCCFG is set to ‘Use incoming’, then because no allocation hints are supplied with these memory types, the default value of Read-Allocate, Write-Allocate, Non-transient is applied to both inner and outer allocation hints. Note: The SMMU architecture only includes configuration of inner and outer properties for the Cacheability of a memory type. No separate inner or outer configuration is provided for RA, WA or TR in any location aside from the translation table descriptor. Attribute overrides for RA, WA and TR affect both inner and outer allocation and transient hints at the same time. 13.1.4 Replace The Replace operation discards any input attribute, replacing a specific attribute with a configured value. For example, the SMMU_GBPA.SHCFG field allows the input Shareability to be discarded and replaced by NSH/ISH/OSH values, or used directly without override, for the purposes of global bypass when the SMMU is disabled. In this specification, the term Override refers to a configuration field that causes an attribute to be replaced with a specific value. The STE fields INSTCFG, PRIVCFG, NSCFG, SHCFG, ALLOCCFG, MTCFG/MemAttr contain override fields that can cause individual input attributes to be replaced with values given in these fields. The effects of STE overrides depend on the transaction type issued to the SMMU. The effects of INSTCFG and PRIVCFG are summarised in Table 13.4. The effects of NSCFG, MTCFG/MemAttr, SHCFG, and ALLOCCFG when SMMU_IDR3.MTCOMB is 0 are summarised in Table 13.5. The effects of NSCFG, MTCFG/MemAttr, SHCFG, and ALLOCCFG when SMMU_IDR3.MTCOMB is 1 are summarised in Table 13.6. Table 13.4: STE.{PRIVCFG, INSTCFG} overrides. Transaction type STE.PRIVCFG STE.INSTCFG Ordinary untranslated read transaction Applies Applies RCI Applies Applies DR Applies Applies Speculative transaction Applies Applies ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1076

Chapter 13. Attribute Transformation 13.1. SMMU handling of attributes Transaction type STE.PRIVCFG STE.INSTCFG Ordinary untranslated write transaction Applies Ignored, always Data Far Atomic operation Applies Ignored, always Data W-DCP Applies Ignored, always Data NW-DCP Applies Ignored, always Data ATS Translation Request Applies Applies ATS Translated Transaction Applies if split-stage or if SMMU_IDR3.PASIDTT is 1 and transaction has a PASID TLP prefix, otherwise IMPLEMENTATION DEFINED Applies if split-stage or if SMMU_IDR3.PASIDTT is 1 and transaction has a PASID TLP prefix, otherwise IMPLEMENTATION DEFINED ATOS Ignored, PnU taken from ATOS_ADDR Ignored, InD taken from ATOS_ADDR CMOs Applies Applies Table 13.5: STE.{NSCFG, MTCFG/MemAttr, SHCFG, ALLOCCFG} overrides when SMMU_IDR3.MTCOMB is 0. Transaction type STE.NSCFG STE.MTCFG/MemAttr STE.SHCFG STE.ALLOCCFG Untranslated Transaction(1) Applies For PCIe, IMPLEMENTATION DEFINED otherwise applies. For PCIe, IMPLEMENTATION DEFINED otherwise applies. For PCIe, IMPLEMENTATION DEFINED otherwise applies. ATS Translation Request Applies IMPLEMENTATION DEFINED IMPLEMENTATION DEFINED IMPLEMENTATION DEFINED ATS Translated Transaction Applies Ignored Ignored IMPLEMENTATION DEFINED ATOS Ignored Ignored Ignored Ignored (1) This includes all Untranslated transactions that are issued by the client device including, ordinary reads/writes, RCI, DR, CMOs, W-DCP, NW-DCP, Far Atomics and speculative transactions. Table 13.6: STE.{NSCFG, MTCFG/MemAttr, SHCFG, ALLOCCFG} overrides when SMMU_IDR3.MTCOMB is 1. Transaction type STE.NSCFG STE.MTCFG/MemAttr STE.SHCFG STE.ALLOCCFG Untranslated Transaction(1) Applies Applies Applies Applies ATS Translation Request Applies Applies Applies Applies ATS Translated Transaction Applies Ignored Ignored Applies ATOS Ignored Ignored Ignored Ignored ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1077

Chapter 13. Attribute Transformation 13.1. SMMU handling of attributes (1) This includes all Untranslated transactions that are issued by the client device including, ordinary reads/writes, RCI, DR, CMOs, W-DCP, NW-DCP, Far Atomics and speculative transactions. For more information on the tables above, see: • STE.PRIVCFG. • STE.INSTCFG. • STE.MTCFG. • STE.MemAttr. • STE.SHCFG. • STE.ALLOCCFG. • 3.9.1.2 Responses to ATS Translation Requests. • 3.9.1.3 Handling of ATS Translated transactions. • 3.22.2 Permissions model. • 16.7.6 Far Atomic operations. • 13.7 PCIe permission attribute interpretation. • 16.7.2.2 Permissions model for Cache Maintenance Operations. • Chapter 9 Address Translation Operations. • 13.1.8 Memory Type Combine (MTCOMB). Similar fields in SMMU_(S_)GBPA allow override of attributes when transactions globally bypass. Whether overrides from STE or SMMU_(S_)GBPA fields take effect is indicated by SMMU_IDR1.ATTR_TYPES_OVR and SMMU_IDR1.ATTR_PERMS_OVR. See SMMU_IDR1 and the field descriptions in Stream Table Entry for more information. When stage 1 translation is used, memory type attributes that are provided by translation table entries replace the attributes provided by the input transaction and any input overrides, if appropriate. This operation is represented by replace_attrs() in pseudocode. Global or STE input overrides are not permitted to make output attributes inconsistent. Because allocation and transient hints are only relevant to Normal cacheable memory types, their overrides in either SMMU_(S_)GBPA or in the STEs do not affect memory types that are not Normal-WB or Normal-WT. The override value is ignored. Similarly, an input type of Device or Normal-iNC-oNC, whether supplied by the client device or overridden in SMMU_(S_)GBPA or in the STE, will always be OSH regardless of any SHCFG override. When an input transaction provides a memory type that is not cacheable and an STE or GBPA input override changes the inner or outer type to a cacheable type, the input RA, WA and TR attributes are taken to be ‘RA, WA, nTR’ (consistent with 13.1.3 Default input attributes), unless these attributes are also overridden. 13.1.5 Combine The result of combining one attribute value with another is governed by rules that are similar to those that apply to SMMUv2 [4] and the Arm Architecture’s [2] combining of stage 1 and stage 2 attributes. The SMMUv3 behavior is the same as that of a PE in that stage 2 translation, when enabled, combines its attribute with those from stage 1, or with the incoming attributes when stage 1 is not enabled. This operation is represented by combine_attrs() in pseudocode. Note: The SMMUv3 behavior with respect to Read-Allocate, Write-Allocate and transient hints with stage 2 differs from SMMUv2 in that SMMUv3 has no stage 2 overrides of RA/WA/TR. However, an order of precedence is defined here to make the pseudocode clearer. The permission-related attributes (R/W, INST, PRIV, NS) are not subject to combine operations. These attributes are only used in the SMMU to check against each enabled stage of translation descriptor permissions. Only MT, SH, RA/WA and TR are combined. Figure 13.1 shows the order of strength for each attribute. When combined, the operation takes the stronger of the values presented. ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1078

Chapter 13. Attribute Transformation 13.1. SMMU handling of attributes Weakest Strongest Weakest Strongest Weakest Strongest Weakest Strongest Normal-WB Normal-WT Device- GRE Device- nGRE Device- nGnRE Device- nGnRnE NSH ISH OSH Allocate No-allocate Non-transient Transient Normal-NC Figure 13.1: Attributes and their order of strength The order for allocate and transient hints is chosen so that allocate and non-transient are the normal cases that are pulled down for no-allocate or transient special cases. 13.1.5.1 Combine examples Normal-iWB/RAWAnTR-oNC-ISH + Device-nGnRE = Device-nGnRE Device-nGnRE + Device-nGnRnE = Device-nGnRnE Normal-iWB/RAWAnTR-oNC-ISH + Normal-iWT/RAWAnTR-oWT/RAnWATR-OSH = Normal-iWT/RAWAnT-oNC-OSH • (Note: outer non-transient even though onTR+oTR = oTR, as outer non-cacheable - see below.) 13.1.6 Stage 2 control of memory types and cacheability Armv8.4 [2] adds the ability for a stage 2 translation to override a stage 1 memory type and Cacheability in order to force a virtual machine access to be a Normal-WB shareable type regardless of the stage 1 configuration. This feature is supported if SMMU_IDR3.FWB == 1. This feature is enabled for a particular stream by setting STE.S2FWB == 1. When enabled, the behavior is as described for the FWB feature in Armv8.4 [2]. Note: The S2FWB bit is per-stream, but is cacheable in the TLB (see section 5.2 Stream Table Entry). In effect, the FWB property is specific to a particular VMID. S2FWB affects the attribute of a translation that is returned using ATOS. If SMMU_IDR3.MTCOMB is 0, then for PCI Express systems, transactions with the No_snoop attribute are not affected by STE.S2FWB. For behavior when SMMU_IDR3.MTCOMB is 1, see section 13.6.1.1 No_snoop. Note: If SMMU_IDR3.MTCOMB is 0, to achieve the effect of all transactions relating to a PCIe function being forced to be coherent WB cacheable, then No_snoop must be disabled in the configuration space of the function and the SMMU configured with STE.S2FWB == 1. This operation is represented by the function combine_attrs_fwb() in the pseudocode. The 2022 Memory Tagging extensions [2] introduced FEAT_MTE_PERM that affects the interpretation of the stage 2 MemAttr field when FWB is enabled or disabled. See section 3.23.1 SMMU support for FEAT_MTE_PERM. ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1079

Chapter 13. Attribute Transformation 13.1. SMMU handling of attributes A transaction is Forced-WB if either of the following applies: • The transaction is subject to stage 2 translation and all of the following apply: – STE.S2FWB == 1. – The stage 2 Page or Block descriptor MemAttr[3:0] field specifies one of the following encodings: * 0b0110. * 0b1110, when SMMU_IDR3.MTEPERM == 1. • The transaction is a translated transaction subject to a DPT check and all of the following apply: – SMMU_IDR3.MTCOMB is 1. – The FWBx field in a DPT entry is 1. 13.1.7 Ensuring consistent output attributes The SMMU does not allow the output of inconsistent attribute combinations. If overrides, translation table configuration or bad input results in inconsistent attributes, the SMMU ensures consistency: • Any-Device and Normal iNC-oNC are output as Outer Shareable • For Normal types, NC at either inner or outer cache level have no RA/WA or TR attributes at that level. A non-cached access is considered to be read-no-allocate, write-no-allocate, non-transient, regardless of programmed read/write allocate and transient configuration. • For Normal types, a cacheable type that is read-no-allocate and write-no-allocate has no TR attribute. Such a type is considered to be non-transient, regardless of any input or programmed override configuration. This also applies to the result of ATOS translation operations. See Chapter 9 Address Translation Operations. Note: In addition to these architectural attribute consistency rules, an implementation might include interconnect-specific consistency rules. See section 16.7.5 SMMU and AMBA attribute differences. 13.1.8 Memory Type Combine (MTCOMB) The Memory Type Combine (MTCOMB) feature provides software with improved control over memory attribute transformation performed by the SMMU. Support for MTCOMB is indicated in SMMU_IDR3.MTCOMB. This feature introduces the following changes: • To prevent loss of coherency arising from misconfiguration or misuse of No_snoop, the effect of No_snoop is no longer applied at the output of the SMMU and is expected to be applied on the incoming memory type before reaching the SMMU. See 13.6.1.1 No_snoop. • To control the propagation of the effect of No_snoop, additional configurable fields are defined in the CD structure and in the DPT. See CD.MTOp and 3.24.3.1 DPT descriptor formats. • The effect of STE.DRE on Forced-WB transactions is modified. • IMPLEMENTATION DEFINED options for applying attribute overrides are removed. See 13.6.1 PCIe memory type attributes. • Rules for applying allocation hints are modified to improve predictability and consistency. See 13.4 Normal translation flow. ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1080

Chapter 13. Attribute Transformation 13.2. SMMU disabled global bypass attributes 13.2 SMMU disabled global bypass attributes When the SMMU is disabled for a given Security state, transactions that belong to that Security state are subject to global bypass attribute overrides. Incoming transaction Construct default for attributes not provided by upstream interconnect Security implemented? Transaction’s SEC_SID input Y SMMU_S_CR0. SMMUEN 1 SMMU_CR0. SMMUEN Locate STE from Secure StreamTable Apply S_GBPA overrides 1 0 N 0 Locate STE from Non- secure StreamTable 1 Apply GBPA overrides Output bypass transaction 0 Translation flow Secure stream Non-secure stream For example, AMBA AXI input does not provide shareability – set as ‘NSH’ A Set NS=1 Ensure consistent attributes SMMU does not output architecturally- inconsistent attributes: Device and Normal-iNC- oNC types must be OSH. Figure 13.2: Input attribute flow - SMMU disabled bypass and start of translation flow When SMMU_S_IDR1.SECURE_IMPL == 0 and SMMU_CR0.SMMUEN == 0, all untranslated transactions bypass the translation and configuration facilities of the SMMU. The memory type, Shareability, Read/Write allocate, Transient, Inst/Data and Privilege attributes of the transaction might be individually replaced by the MTCFG/MemAttr, SHCFG, ALLOCCFG, INSTCFG and PRIVCFG override fields of the SMMU_GBPA register, respectively. Each attribute might take a set value or select to Use incoming. In the latter case, the attribute is either taken from the incoming interconnect or, when not supplied, the default input attribute constructed in the ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1081

Chapter 13. Attribute Transformation 13.2. SMMU disabled global bypass attributes SMMU. Apart from these overrides, the transaction is output directly. For some classes of transaction, for example Cache Maintenance Operations, the SMMU may apply protocol-specific normalization on the output transaction attributes. Note: When the SMMU is disabled, ATS Translation Requests and ATS-translated transactions are terminated by the SMMU. See section 3.9.1.2 Responses to ATS Translation Requests. Alternatively, when SMMU_S_IDR1.SECURE_IMPL == 0 and SMMU_CR0.SMMUEN == 1, an STE is located and the translation flow begins. When SMMU_S_IDR1.SECURE_IMPL == 1, the behavior of a transaction on arrival at the SMMU is determined by the Security state of its StreamID, as determined by the SEC_SID input, see section 3.10.1 StreamID Security state (SEC_SID). If the stream is Non-secure and SMMU_CR0.SMMUEN == 0, the attributes are overridden by SMMU_GBPA as described earlier in this section. If the stream is Secure and SMMU_S_CR0.SMMUEN == 0, the attributes are determined by SMMU_S_GBPA in the same way, otherwise a Secure STE is located and the translation flow begins. The output NS attribute is determined by SMMU_S_GBPA.NSCFG, it can use the incoming value or be overridden to either state. The reset state of the bypass attribute register SMMU_GBPA, and when SMMU_S_IDR1.SECURE_IMPL == 1 SMMU_S_GBPA, is IMPLEMENTATION DEFINED. Note: The SMMU might provide an implementation-time configuration of the default bypass attributes which allows a system designer to ensure that device DMA has useful attributes even if system software has not initialized the SMMU. Arm recommends that the default attributes are set as appropriate for the system in accordance with relevant base system architecture definitions. This case is illustrated by this pseudocode: // See 13.1.3: Attrs input_attrs = add_defaults_for_unsupplied(upstream_attrs); bool secure = (SEC_SID == SEC_SID_Secure); if (secure) { output_attrs = replace_attrs(SMMU_S_GBPA, input_attrs); } else { output_attrs = replace_attrs(SMMU_GBPA, input_attrs); output_attrs.NS = 1; } // MT, SH, RA, WA, TR, INST, PRIV are unchanged or overridden, // depending on respective register field. // // NS is unchanged or overridden if secure stream, otherwise // fixed at 1. // See 13.1.7: output_attrs = ensure_consistent_attrs(output_attrs); ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1082

Chapter 13. Attribute Transformation 13.3. Translation flow, STE bypasses stage 1 and stage 2 13.3 Translation flow, STE bypasses stage 1 and stage 2 A second type of SMMU bypass is available when the SMMU is enabled. This is when a StreamID selects an STE configured to bypass (STE.Config == 0b100). SMMU_GBPA and SMMU_S_GBPA are not used, and a finer-grained per-STE configuration is available. Refer to the no-translate case of Figure 13.3. The STE fields MTCFG, MemAttr, ALLOCCFG, SHCFG, NSCFG, PRIVCFG and INSTCFG can override any attribute before the transaction is passed to the memory system. This provides per-StreamID granularity of attribute settings. Each attribute might take a set value or select to Use incoming. Where the incoming attribute is use, the attribute is either taken from the incoming interconnect or, when not supplied, the default input attribute constructed in the SMMU. Pseudocode: // See 13.1.3: Attrs input_attrs = add_defaults_for_unsupplied(upstream_attrs); STE ste = get_STE_for_stream(StreamID); output_attrs = replace_attrs(ste, input_attrs); if (!ste.fetched_for_secure_stream()) { output_attrs.NS = 1; } // MT, SH, RA, WA, TR, INST, PRIV are unchanged or overridden, // depending on respective STE field. // // NS is unchanged or overridden if secure stream, otherwise // fixed at 1. output_attrs = ensure_consistent_attrs(output_attrs); ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1083

Chapter 13. Attribute Transformation 13.4. Normal translation flow 13.4 Normal translation flow STE: Stage1 translates? Apply STE overrides for PRIV, INST, NS perms A MT replaced with values from S1 translation descriptor/MAIR attributes Y STE: Stage2 translates? N MT, SH combined with S2 translation descriptor attrs Note: If input to S2 is Normal-NC or stronger, but FWB forces WB, then RA, WA are set to no- allocate, otherwise RA, WA, TR are unmodified. Y Output attributes N Set NS from descriptor.NS and intermediate NSTable flags Check R/W, PRIV, INST against page permissions Ensure consistent attributes (From previous chart) Secure stream or Realm EL2/EL2&0 only Note: PRIV is not checked in SMMUv3.0 or in implementations where SMMU_IDR3.XNX==0 Apply STE overrides for MT, SH, RA, WA, TR attrs For Non-secure stream, set NS=1. For Secure stream, set NS from stage 2 translation table configuration. For Realm stream, set NS from stage 2 translation table descriptor. Select S2 translation table from S1 NS output Secure stream only CD.MTOp MT combined with values from S1 translation descriptor/MAIR attributes 1 0 Check R/W, PRIV, INST against page permissions RA, WA, TR combined with values from S1 translation descriptor/MAIR attributes SH replaced with values from S1 translation descriptor/MAIR attributes SH made consistent with MT Figure 13.3: Attribute determination in translation ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1084

Chapter 13. Attribute Transformation 13.4. Normal translation flow When the StreamID of a transaction selects an STE configuration with two stages of translation, the memory attribute of the transaction is determined by the stage 1 AttrIndex descriptor attribute and the MAIR fields, and combined with the stage 2 MemAttr descriptor attribute. For stage 1-only translations, all of the following are true: • If SMMU_IDR3.MTCOMB is 0, the memory attributes are determined solely by the stage 1 descriptor attributes. • If SMMU_IDR3.MTCOMB is 1, the input memory type can be configured to combine with the stage 1 descriptor memory type. For stage 2-only translations, the memory attributes are determined by the input attribute, with STE overrides, combined with the stage 2 descriptor attributes. First, the incoming attributes, with defaults constructed for any unsupplied attributes, are subject to the STE override described in section 13.3 Translation flow, STE bypasses stage 1 and stage 2. These attributes are provided to the first enabled stage of translation. If stage 1 bypasses, these attributes are provided to stage 2 directly. If stage 1 translates, then all of the following are true: • If SMMU_IDR3.MTCOMB is 0, the stage 1 attributes are determined by the stage 1 descriptor in combination with the MAIR fields of the CD. • If SMMU_IDR3.MTCOMB is 1, the stage 1 attributes are determined by the stage 1 descriptor in combination with the input memory type. Page permissions are determined by the stage 1 descriptor, in combination with fields of the CD. The R/W, PRIV and INST attributes, as modified by STE overrides, are checked against the page permissions. 13.4.1 Stage 1 page permissions When using the Direct Permission Scheme for stage 1, the effect of the lower bit of the stage 1 descriptor AP[2:1] field, AP[1], changes depending on the translation regime under which the translation is performed, as determined by StreamWorld. For EL1 or for any-EL2-E2H, the AP[1] bit controls the EL0 access permissions of the page (PRIV == 0). However, when StreamWorld == any-EL2 or StreamWorld == EL3, the AP[1] bit is ignored and treated as if it were 1. This has the same effect as treating PRIV == 1 for the purposes of permission checking, which means that input PRIV attributes and any STE.PRIVCFG overrides are ignored for these checks. When PRIV and INST attributes are output to the memory system, they are presented as the result of applying the STE.PRIVCFG and STE.INSTCFG overrides to the input attribute. They are not modified after this point. See section 3.26.1 Stage 1 permission indirections for when stage 1 is configured to use the Indirect Permission Scheme. 13.4.2 Stage 1 memory attributes For the attributes determined from the stage 1 translation table descriptor and CD.MAIR, all of the following are true: • If SMMU_IDR3.MTCOMB is 0, they are provided directly to the stage 2 translation. The incoming attributes, including any STE overrides, are discarded and replaced by the stage 1 attributes, with the exception of RA/WA/TR. • If SMMU_IDR3.MTCOMB is 1, they are subject to CD.MTOp which can be configured to combine or replace the incoming memory type, including any STE overrides, before being provided to the stage 2 translation. When the translation is from a Secure StreamID, the target IPA or PA space from stage 1 is determined directly from the effective NS bit of the descriptor, which must take into account the value of NSTable flags on intermediate Table descriptors in addition to the final descriptor NS flag, in the same way as on the PE. In addition, CDs that are used with Secure streams contain NSCFGx flags that determine the starting NS attribute of translation table walks ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1085

Chapter 13. Attribute Transformation 13.4. Normal translation flow performed through CD.TTB0/1. When a translation is fetched using a CD.TTB0/1 with a corresponding NSCFGx == 1, the stage 1 targets Non-secure IPA or PA space. When a translation is from a Non-secure stream, the output NS attribute that is output is always 1 and the NS attribute that was input with the transactions is ignored. When Secure stage 2 is supported and enabled, the final transaction NS bit depends on the configuration of the stage 2 IPA space, STE.{S2NSA, S2NSW, S2SA, S2SW}. See section 3.10.2.2 Secure EL2 and support for Secure stage 2 translation. Otherwise, the final transaction uses the target IPA space from stage 1, or stage 1 bypass. Note: The behavior of the input NS attribute in a stage 1-only configuration matches the SMMUv2 [4] behavior in that the input NS attribute is wholly determined by the stage 1 descriptor and translation table walk configuration. The input NS attribute and STE override only affect the target IPA or PA space when no stage 1 translation is configured. When the attribute input to stage 1 is a Normal-cacheable type, the RA/WA/TR attributes are not discarded and instead are combined with those determined from the stage 1 translation descriptor and CD.MAIR. Any other type does not communicate RA/WA/TR hints, in which case the stage 1 translation RA/WA/TR attributes are used directly. If SMMU_IDR3.MTCOMB is 1, the SMMU can be configured to combine the the incoming memory type, including any STE overrides. If the memory type after applying CD.MTOp is not Normal-cacheable type, then the RA/WA/TR hints are not communicated. All other attributes are overridden by stage 1 translation table attributes. Note: This property, combined with STE.ALLOCCFG == 0b0xxx configuration, allows a client device to influence per-transaction allocation/transient attributes when using stage 1 translation tables, allowing sub-page control. 13.4.3 Stage 2 If stage 2 bypasses, the attributes provided by the incoming transaction or the stage 1 translation are forwarded unchanged to the memory system. If stage 2 translates, the MT and SH attributes input to stage 2 undergo a combine operation with the stage 2 translation descriptor attributes to produce the output attributes. If STE.S2FWB == 1, then the combine operation uses the encoding and behavior of the stage 2 translation descriptor attributes for the FWB feature as described in Armv8.4 [2]. If stage 2 translates, then for each cacheability domain where the final memory type is any Normal cacheable type, all of the following apply: • If the input to stage 2 specifies any Normal cacheable memory type, then the final cache allocation hints are the stage 2 input cache allocation hints. • If the input to stage 2 does not specify any Normal cacheable memory type, then the final cache allocation hints are as follows: – If SMMU_IDR3.MTCOMB is 1: Read No-Allocate, Write No-Allocate. – If SMMU_IDR3.MTCOMB is 0: Read-Allocate, Write-Allocate, Non-transient. Note: This includes the following cases: • CD.MTOp is 0 and the memory type defined by stage 1 descriptor is Normal-NC or any-Device. • CD.MTOp is 1 and the incoming memory type after applying STE.MemAttr is Normal-NC or any-Device. • STE.EATS is 0b10 (Split-stage ATS) and the incoming memory type of a Translated transaction is Normal-NC or any-Device. The INST attribute is checked, along with R/W, to evaluate stage 2 permissions. If SMMU_IDR3.XNX == 0, the PRIV attribute is not used to evaluate stage 2 permissions. If SMMU_IDR3.XNX == 1, the PRIV attribute is used to evaluate stage 2 permissions. When using the Direct Permission Scheme, stage 2 checks are performed against the descriptor page permissions. See section 3.26.2 Stage 2 permission indirections for when stage 2 is configured to use the Indirect Permission Scheme. ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1086

Chapter 13. Attribute Transformation 13.4. Normal translation flow 13.4.4 Output The transaction is output after ensuring consistency of the attributes and forcing NS == 1 for transactions on Non-secure streams. Pseudocode, which also illustrates the cases describe in sections 13.2 SMMU disabled global bypass attributes and 13.3 Translation flow, STE bypasses stage 1 and stage 2 in more detail, is show below: // See 13.1.3: Attrs input_attrs = add_defaults_for_unsupplied(upstream_attrs); bool secure = (SEC_SID == SEC_SID_Secure); if (secure && SMMU_S_CR0.SMMUEN == 0) { output_attrs = replace_attrs(SMMU_S_GBPA, input_attrs); // See 13.1.7: output_attrs = ensure_consistent_attrs(output_attrs); output_transaction(output_attrs); // Address, direction not shown // Done. } // Else carry on below if (!secure && SMMU_CR0.SMMUEN == 0) { output_attrs = replace_attrs(SMMU_GBPA, input_attrs); output_attrs.NS = 1; // See 13.1.7: output_attrs = ensure_consistent_attrs(output_attrs); output_transaction(output_attrs); // Address, direction not shown // Done. } // Else carry on below // If we get to here, the appropriate SMMU interface is enabled and // configuration can be fetched: STE ste = get_STE_for_stream(StreamID); Attrs i; // Starting attributes are as input, with STE overrides: i = replace_attrs(ste, input_attrs); if (ste.s1_translates()) { Attrs s1_attrs; TTD s1_ttd; CD cd = get_CD(ste, StreamID, SubstreamID, SubstreamID_valid); s1_ttd = s1_translation(cd, ste); // Address not shown; IPA determined from VA. NS of stage 1 translation // table walk depends on CD.NSCONFIGx and is not shown here. s1_attrs = s1_ttd.lookup_attrs(); // The returned s1_attrs contains attributes determined from the // translation descriptor and MAIR, including RA/WA and TR. if (s1_ttd.translation_fault()) { // XXXX Stage 1 translation fault // Note: A speculative read transaction is simply terminated // with abort here, without recording an event. } // Note: Permission checking must consider HTTU configuration, // and update Access flag and Dirty state instead of signaling a related fault // when HTTU enabled: if (check_perms_and_httu(cd, s1_ttd, i.RW, i.INST, i.PRIV) == FAULT) { // XXXX Stage 1 permissions or Access flag fault // Note: EL2 or AArch64 EL3 stage 1 do not check PRIV, // i.e. client traffic behaves as if PRIV == 1. However, // the PRIV attribute is not modified. ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1087

Chapter 13. Attribute Transformation 13.4. Normal translation flow } // Note: See section 13.4.2; when a cached type is input to Stage 1, // s1_attrs.{RA,WA,TR} are combined with i.{RA,WA,TR} instead of // replacement (non-cached/Device types do not express RA/WA/TR // attributes): if (is_cached_type(i.MT)) { i.{RA,WA,TR} = combine_attrs(i.{RA,WA,TR}, s1_attrs.{RA,WA,TR}); } else { // An input NC/Device type does not provide these attributes, // so take these attributes from S1: i.{RA,WA,TR} = s1_attrs.{RA,WA,TR}; } // If CD.MTOp is configured to combine, the Stage 1 MT is combined with // the incoming MT. Otherwise MT is taken directly from Stage 1. // SH is always taken directly from Stage 1: if CD.MTOp == 1 { i.MT = combine_attrs(s1_attrs.MT, i.MT); } else { i.MT = s1_attrs.MT; } i.SH = s1_attrs.SH // NS is taken from the 'effective' value calculated from // S1 Block or Page descriptor, CD.NSCONFIGx and appropriate NSTable bits: i.NS = s1_ttd.get_effective_NS(); // RW, INST, PRIV do not change. } else { // MT, SH, RA, WA, TR unchanged; and RW, INST, PRIV, NS // permissions passed through. } if (ste.s2_translates()) { Attrs s2_attrs; TTD s2_ttd; // Fetch stage 2 translation table descriptor. // Address not shown; PA determined from IPA and HTTU is performed. if (secure) { // Perform S-IPA or NS-IPA translation table walk with given NS: bool sipa_s2_ttw_ns = ste.S2SW; bool nsipa_s2_ttw_ns = ste.S2NSW; // Final NS is a function of the walk NS: bool sipa_ns = sipa_s2_ttw_ns || ste.S2SA; bool nsipa_ns = nsipa_s2_ttw_ns || sipa_ns || ste.S2NSA; // The NS input to stage 2 indicates the NS or S IPA space. if (i.NS) { s2_ttd = s2_translation_ns_ipa(ste, nsipa_s2_ttw_ns); i.NS = nsipa_ns; } else { s2_ttd = s2_translation_s_ipa(ste, sipa_s2_ttw_ns); i.NS = sipa_ns; } } else { // Non-secure stream s2_ttd = s2_translation(ste); } s2_attrs = s2_ttd.lookup_attrs(); if (s2_ttd.translation_fault()) { // XXX Stage 2 translation fault // Note: On any fault, a speculative read transaction is simply // terminated with abort. ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1088

Chapter 13. Attribute Transformation 13.4. Normal translation flow // Note: HTTU at Stage 1 is permitted, even if we fault @S2 } // S2 does not encode RA/WA/TR; these values plus combine_attrs() below // result in "take input from S1/previous step" behavior for RA/WA/TR: s2_attrs.RA_inner = true; s2_attrs.RA_outer = true; s2_attrs.WA_inner = true; s2_attrs.WA_outer = true; s2_attrs.TR_inner = false; s2_attrs.TR_outer = false; if (s2_ttd.S2FWB == 0) { // MT, SH, RA, WA, TR updated via combine: i = combine_attrs(i, s2_attrs); } else { // combine_attrs_fwb() treats the encoding of stage 2 // attribues as defined for the FWB features in Armv8.4 i = combine_attrs_fwb(i, s2_attrs); } // See HTTU note in Stage 1: if (check_perms_and_httu(ste, s2_ttd, i.RW, i.INST, i.PRIV) == FAULT) { // XXXX Stage 2 permissions or Access flag fault // Note: S2 checks PRIV if SMMU_IDR3.XNX == 1. } } else { // MT, SH, RA, WA, TR unchanged; and RW, INST, PRIV, NS // permissions passed through. } // Finally, a Non-secure stream is not permitted to output NS == 0; // the overrides and page attribute are ignored: if (!secure) { output_attrs.NS = 1; } // MT, SH, RA, WA, TR may be modified by translations and overrides. // INST, PRIV may be modified by STE overrides. // // For a secure stream, stage 1 output NS is determined from the Stage 1 // translation (if present), otherwise is the STE override or input value. // This is used to select an IPA space in stage 2, or output directly if no // stage 2. // See 13.1.7: output_attrs = ensure_consistent_attrs(output_attrs); output_transaction(output_attrs); // Address, direction not shown // Done. ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1089

Chapter 13. Attribute Transformation 13.5. Summary of attribute/permission configuration fields 13.5 Summary of attribute/permission configuration fields The attributes output from the SMMU are determined as follows. If translation occurs If bypass Attribute Stage 1-only Stage 1 + stage 2 Stage 2-only SMMUEN == 1 but STE.Config == 0b100 SMMUEN == 0 INST Data, if required by the memory system. PRIV Privileged, if required by the memory system. PA space (Secure stream) Effective S1_TTD.NS, NSTable and CD.NSCFGx Effective S1_TTD.NS, NSTable CD.NSCFGx and STE.{S2NSA, S2NSW, S2SA S2SW} STE.NSCFG and STE.{S2NSA, S2NSW, S2SA S2SW} STE.NSCFG SMMU_S_GBPA .NSCFG PA space (Realm stream) EL1: Fixed, Realm PA space. EL2 or EL2-E2H: S1_TTD.NS S2_TTD.NS S2_TTD.NS STE.NSCFG Transaction aborted PA space (Non- secure stream) Fixed, Non-secure PA space MT Combine(STE. {MemAttr, MTCFG}, CD.MAIR[ S1_TTD.AttrIndx], CD.MTOp) Combine(STE. {MemAttr, MTCFG}, CD.MAIR[ S1_TTD.AttrIndx], S2_TTD.MemAttr, STE.S2FWB, CD.MTOp) Combine(STE. {MemAttr, MTCFG}, S2_TTD.MemAttr, STE.S2FWB) STE. {MemAttr, MTCFG} SMMU_(S_) GBPA. {MemAttr, MTCFG} RA, WA, TR CD.MAIR[ S1_TTD.AttrIndx], if STE.{MemAttr, MTCFG} provide any-Device or NC input to Stage 1, otherwise: Combine( STE.ALLOCCFG, CD.MAIR[ S1_TTD.AttrIndx]) CD.MAIR[ S1_TTD.AttrIndx], if STE.{MemAttr, MTCFG} provide any-Device or NC input to Stage 1, otherwise: Combine( STE.ALLOCCFG, CD.MAIR[ S1_TTD.AttrIndx]) Combine( STE.ALLOCCFG, S2_TTD.MemAttr) STE.ALLOCCFG SMMU_(S_) GBPA. ALLOCCFG ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1090

Chapter 13. Attribute Transformation 13.5. Summary of attribute/permission configuration fields If translation occurs If bypass Attribute Stage 1-only Stage 1 + stage 2 Stage 2-only SMMUEN == 1 but STE.Config == 0b100 SMMUEN == 0 SH S1_TTD.SH Combine ( S1_TTD.SH, S2_TTD.SH) Combine ( STE.SHCFG S2_TTD.SH) STE.SHCFG SMMU_(S_) GBPA.SHCFG Notes: • Permission checking of InD and PnU against translation descriptor fields is not shown here. • References to INSTCFG, PRIVCFG, NSCFG, MTCFG/MemAttr and ALLOCCFG refer to the effective output of these override fields, which might always be the incoming attribute depending on SMMU_IDR1.ATTR_PERMS_OVR and SMMU_IDR1.ATTR_TYPES_OVR. This table does not show the effect of one field on another field. For example, the configuration used to determine allocation/transient hints or Shareability is irrelevant if the MemType is of any-Device type. See section 16.7.5 SMMU and AMBA attribute differences for other interconnect-specific dependencies between attributes. • (a): If stage 2 translation is enabled, and STE.S2FWB==1, the Combine() operation for memory is instead an override operation for some values of the stage 2 MemAttr field. ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1091

Chapter 13. Attribute Transformation 13.6. PCIe and ATS attribute/permissions handling 13.6 PCIe and ATS attribute/permissions handling This section covers an area of system architecture that intersects with the SMMU operation. Integration of PCIe, particularly with ATS, requires consideration of the presentation of transactions to the SMMU from the Root Complex and the overall system architecture, including platform definitions such as the Base System Architecture [12] and Server Base System Architecture [13], in addition to that of the SMMU itself. In many systems it will be typical to have a discrete Root Complex IP block connected to a downstream SMMU IP block by a standard piece of interconnect fabric, for example using AXI. This section considers the attributes provided to the SMMU by the Root Complex on such an upstream interconnect in relation to the output attributes provided by the SMMU downstream into the system. Note: An ATS client makes a Translation Request to the SMMU and caches the resulting Physical Address in its local Address Translation Cache (PCIe terminology for a remote TLB). When a client has successfully received a translation, it might use it later to make direct physically-addressed (Translated) accesses to the page, which are intended to bypass SMMU translation altogether. However, the PCIe [1] ATS protocol does not explicitly provide a field to convey a memory type/access attribute to the client in the completion of the Translation Request. Therefore, the subsequent Translated transaction is issued from the endpoint with no attributes (beyond R/W) unless ATS attributes are supported. 13.6.1 PCIe memory type attributes PCIe does not contain memory type attributes, and each transaction takes a system-defined memory type when it progresses into the system. The Base System Architecture [12] requires the intial memory type to be Normal cacheable shareable (IO-coherent) before No_snoop transformations are taken into account. Note: When PCIe is used with an SMMU, the SMMU can assign a different attribute if necessary, but the common usage model is for PCIe DMA to remain Normal cacheable shareable and the SMMU is primarily used for address transformation/protection rather than attribute assignment. Note: The Base System Architecture [12] requires that, when no SMMU is present or an SMMU is present and in global or stream bypass mode, a transaction from a Root Complex targeted at memory is presented to the memory system with a fixed attribute of Normal cacheable shareable. The exact attribute will be Normal-iWB-oWB-ISH or OSH and is system-dependent, but is considered fixed/static because PCIe does not encode different memory types. The system must treat transactions that are targeted at devices (such as MSIs) as Device type accesses. The incoming attributes of Untranslated transactions forwarded to the SMMU by the Root Complex are as follows: • If SMMU_IDR3.MTCOMB is 0, Untranslated transactions have the fixed Normal cacheable shareable attribute. • If SMMU_IDR3.MTCOMB is 1, Untranslated transactions have either: – The Normal cacheable shareable attribute. – The Normal non-cacheable attribute. When an SMMU is used with translation (i.e., not in bypass mode), the SMMU might be configured to use Stage 1/Stage 2 translation and/or STE input overrides, determining an output attribute from a function of the input, translation table descriptor and override attributes as described previously in this chapter. The final attribute is defined by software configuration. Note: See No_snoop below, which might alter the final output attribute if SMMU_IDR3.MTCOMB is 0. If SMMU_IDR3.MTCOMB is 0, it is IMPLEMENTATION DEFINED whether attribute overrides affect streams associated with PCIe devices or whether the incoming attribute is used. See: • STE.MTCFG. • STE.ALLOCCFG. • STE.SHCFG. • SMMU_GBPA.MTCFG. • SMMU_GBPA.ALLOCCFG. • SMMU_GBPA.SHCFG. ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1092

Chapter 13. Attribute Transformation 13.6. PCIe and ATS attribute/permissions handling 13.6.1.1 No_snoop Note: In PCIe, No_snoop is not guaranteed to be supported by a device or Root Complex, and if it is supported by a device, it might be disabled via configuration space. When a transaction includes a No_snoop == 1 flag, it indicates that the transaction is allowed to “opt-out” of hardware cache coherency; software cache coherency ensures the access would not hit in a cache, so the I/O access is permitted to avoid snooping caches. In an Arm system, a No_snoop access corresponds to Normal-iNC-oNC-OSH. Support for No_snoop is system-dependent. If No_snoop is supported, then the way in which No_snoop interacts with the SMMU is dependent on the value of SMMU_IDR3.MTCOMB. If SMMU_IDR3.MTCOMB is 0 then all of the following apply: • No_snoop transforms a final access attribute of a Normal cacheable type to Normal-iNC-oNC-OSH downstream of (or appearing to be performed downstream of) the SMMU. No_snoop does not transform a final access attribute of any-Device. • No_snoop applies after the application of the STE.S2FWB bit. Note: To achieve this “pull-down” behavior, the No_snoop flag might be carried through the SMMU and used to transform the SMMU output downstream. If SMMU_IDR3.MTCOMB is 1 then all of the following apply: • The SMMU does not transform the memory type based on the No_snoop attribute. Instead, No_snoop is applied on the incoming memory attributes as specified in the Arm Base System Architecture [12]. • Software should configure CD.MTOp to combine, such that the SMMU permits the effect of No_snoop to propagate to the memory system downstream of the SMMU. • Transactions are still subject to stage 2 and DPT controls, if enabled. This means that if a transaction is Forced-WB, then the PCIe No_snoop attribute does not affect the output memory type regardless of the value of CD.MTOp. 13.6.2 ATS attributes overview The SMMU determines the output attributes of Untranslated transactions from a function of input, input overrides and translation tables. Therefore, the output attributes are address-dependent. When an ATS Translated transaction is forwarded to the SMMU, it may bypass address translation depending on the value of STE.EATS. The memory attributes of an ATS Translated transaction before the effects of No_snoop are applied are an IMPLEMENTATION DEFINED choice of one of the following: • Normal cacheable shareable. • Memory attributes consistent with those that would result from an Untranslated transaction to the same address. This can result from using ATS attributes. Note: For example, ATS attributes might be supported by leveraging the PCIe AMA field to assign Arm-specific attributes to ATS Translated transactions. Note: If ATS attributes are not supported, the resulting output attributes of an ATS Translated transaction may differ from those of a non-ATS/Untranslated access to the same address. This is acceptable in systems where such a mismatch does not compromise correctness. If SMMU_IDR3.MTCOMB is 0, and ATS attributes are supported by the SMMU, the SMMU modifies the attributes of the transaction as appropriate for the accessed page. If SMMU_IDR3.MTCOMB is 1, the SMMU expects ATS attributes to be applied at the input to the SMMU, and that the effect of No_snoop is additionally applied to the attributes of ATS Translated transactions before they are presented to the SMMU. These attributes are still subject to stage 2 and DPT controls, if enabled. Note: Where No_snoop is applied, ATS Translated transaction input memory attributes are Normal non-cacheable. ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1093

Chapter 13. Attribute Transformation 13.6. PCIe and ATS attribute/permissions handling If SMMU_IDR3.MTCOMB is 1, and the SMMU supports encoding memory attributes into ATS Translation Completions, Arm recommends that the SMMU also encodes the value of the output allocation hints. This enables devices to supply allocation hints for Translated transactions using ATS. If SMMU_IDR3.MTCOMB is 1 and SMMU_(R_)CR0.ATSCHK is 1, then STE.ALLOCCFG applies to incoming memory attributes of Translated transactions in addition to Untranslated transactions. Note: In versions of the SMMU architecture up to and including SMMUv3.3, an SMMU implementation might store translation-specific attributes in the otherwise unused, most significant bits of the physical address fields in ATS Translation Completions and ATS Translated transactions. This is referred to as Attribute stashing. In SMMUv3.3 implementations, if SMMU_ROOT_IDR0.REALM_IMPL == 1, the SMMU never performs Attribute stashing, and always returns zeros in the most significant bits of the physical address field above its implemented physical address size in ATS Translation Completions. From SMMUv3.4, Attribute stashing is forbidden. 13.6.2.1 Supporting No_snoop with ATS If SMMU_IDR3.MTCOMB is 0, then all of the following apply: • If the SMMU supports the encoding of attributes into ATS, the mechanism for determining the ATS Translated attributes in the SMMU is independent of the subsequent application of a No_snoop non-cacheable/downgraded attribute. • The N field in ATS Translation Completions is always 0. The SMMU does not provide the means to control No_snoop per-page. If SMMU_IDR3.MTCOMB is 1, then all of the following apply: • If the SMMU supports the encoding of attributes into ATS, then No_snoop is expected to be applied on attributes supplied with Translated transactions before being processed by the SMMU. • Arm recommends that the N field is set to 1 when any of the following apply: – The ATS Translation Request is Forced-WB. – The ATS Translation Request is subject to stage 1 and all of the following apply: * CD.MTOp is configured to replace the incoming memory type. * The resultant memory type is Normal-iWB-oWB. 13.6.3 Split-stage (STE.EATS == 0b10) ATS behavior and responses When Split-stage ATS is enabled for a stream (that is, when STE.EATS == 0b10, SMMU_CR0.ATSCHK == 1 and STE.Config == 0b111), the response to an ATS Translation Request contains an IPA. When a Translated transaction is emitted as a result of this response, its IPA then undergoes stage 2 translation in the SMMU. Note: In effect, the stage 1 VA to IPA translation is held in the ATC but stage 2 IPA to PA translation is still performed in the SMMU. This can be used to increase security/isolation over regular nested EATS == 0b01 ATS, where the system does not trust the endpoint to use physical addresses directly. The behavior of Split-stage ATS is the same as regular EATS ==0b01 ATS with nested translation, except: • The completion contains the IPA result from the Stage 1 translation of the requested VA (instead of the output PA from stage 1+stage 2 translation of the requested VA). • If the SMMU supports the encoding of attributes into ATS (see section 13.6.2 ATS attributes overview), an attribute is returned that gives a final output equivalent to the Stage 1+Stage 2 combined attribute when the resulting ATS Translated transaction is subject to stage 2 translation in the SMMU. This may be implemented in any of the following ways: – Returning a Stage 1 attribute that is later combined with stage 2 attributes. – Returning a Stage 1+2 combined attribute that is later combined again with stage 2 attributes (which gives the same result). – Returning a Stage 1+2 combined attribute that is not later combined with stage 2 attributes. This is permitted only if SMMU_IDR3.MTCOMB is 0. • HTTU might be performed by the stage 2 translation that occurs as part of the ATS Translation Request, or it might be performed at the time of the stage 2 translation for a subsequent Translated transaction. ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1094

Chapter 13. Attribute Transformation 13.6. PCIe and ATS attribute/permissions handling All other aspects are identical to regular EATS == 0b01 ATS with nested translation: • Permissions are granted from the combination of the stage 1 and stage 2 translation permissions (see 13.7 PCIe permission attribute interpretation), with respect to the permissions requested in the Translation Request. • The maximum permissible translation size is derived from the intersection of stage 1 and stage 2 page/block sizes. Arm recommends that, for performance reasons, the maximum translation size is returned where possible. – Note: The largest translation size is the minimum of the stage 1 and stage 2 translation sizes for the given address, such that the returned translation represents a single span with constant permission and translation. See 13.6.5 Split-stage ATS skipping stage 1 for behavior of STE.S1DSS skipping stage 1. The behavior of an incoming Translated transaction differs depending on the EATS configuration of the StreamID presenting the transaction: • When EATS == 0b01, the Translated transaction is presented directly to the output. The given address is treated as a PA. The output attributes are one of the following: – If the SMMU supports the encoding of attributes into ATS: the attributes encoded in the translated transaction. – Otherwise: the Normal cacheable shareable attribute. Note: In both cases, if SMMU_IDR3.MTCOMB is 0 the SMMU transforms the output attributes based on No_snoop. If SMMU_IDR3.MTCOMB is 1, the effect of No_snoop (if present) is expected to be applied before transactions are processed by the SMMU. Therefore, the output attribute can be Normal non-cacheable. • When EATS == 0b10, the Translated transaction provides an IPA. The output attributes are one of the following: – If the SMMU supports encoding of attributes into ATS: the attributes in the Translated transaction combined with stage 2 attributes. Note: This might be implemented as returning a Stage 1+2 combined attribute in the ATS Translation Completion, and the attributes supplied with the Translated transaction are then passed through and do not later combine with stage 2 attributes. This is permitted only if SMMU_IDR3.MTCOMB is 0. – If the SMMU does not support encoding of attributes into ATS: Normal cacheable shareable combined with stage 2 attributes. Note: In both cases, if SMMU_IDR3.MTCOMB is 0 the SMMU transforms the output attributes based on No_snoop. If SMMU_IDR3.MTCOMB is 1, the effect of No_snoop (if present) is expected to be applied before the transaction is processed by the SMMU (before being combined with stage 2 attributes). The behavior for permission attributes overrides on ATS Translated transactions is described in 13.7 PCIe permission attribute interpretation. EATS == 0b10 configuration is only usable when SMMU_CR0.ATSCHK == 1. Note: ATSCHK == 1 causes Translated transactions to look up and be checked against STE configuration, which for EATS == 0b10 provides the stage 2 with which to translate and for EATS == 0b01 allows the transaction to bypass without translation. 13.6.4 Full ATS skipping stage 1 When all of the following are true, transactions arriving without a PASID are configured to skip stage 1 translation: STE.Config == 0b1x1 (Stage 1 translation enabled) STE.EATS == 0b01 (“Full ATS” enabled) ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1095

Chapter 13. Attribute Transformation 13.6. PCIe and ATS attribute/permissions handling STE.S1CDMax != 0 (Substreams/PASIDs enabled) STE.S1DSS == 0b01 (non-PASID transactions bypass Stage 1) If stage 2 translation is enabled (STE.Config == 0b11x), an ATS Translation Request without a PASID is translated stage 2-only as though STE.Config[1:0] == 0b10. The Translation Completion returns a PA from the stage 2-only translation. Where a stage 1 + stage 2 configuration has the first stage skipped due to STE.S1DSS == 0b01, the translation process behaves as though stage 1 were not configured (corresponding to STE.Config == 0b1x0). If ATS attributes are supported, the final attribute is therefore determined by the upstream input attribute (if provided), replaced by STE overrides where configured, and combined with the attribute from the stage 2 translation table descriptor. If stage 2 is not enabled, an ATS Translation Request without a PASID made to this configuration skips the single translation stage and, if a fault or configuration error has not occurred, its Translation Completion returns a direct-mapped “pass-through” of the stage. Responses to requests that lead to faults and configuration errors are described in section 3.9.1.2 Responses to ATS Translation Requests. This is encoded as an identity-mapped Translation Completion containing: • U == 0 • R == 1 • W == 1 • TranslatedAddress 1:1/identity-mapped with the Untranslated Address provided in the Translation request. • Translation size containing at least the requested Untranslated Address – Note: An implementation might return a larger identity-mapped region, as any address accessed under the same StreamID/configuration conditions will result in this type of response. A larger region might avoid future page-by-page translation requests. – The maximum permissible translation size is the same as the OAS (see section 3.4 Address sizes). • Note: As this response is made for an ATS Translation Request received without a PASID, the request cannot contain Execute_Requested == 1 or Privileged_Mode_Requested == 1 as these fields are carried in a PASID. The response is made with Execute_Permitted and Privileged_Mode_Access both 0. • Note: This response causes the function to make 1:1 accesses to physical addresses, equivalent to the behavior of untranslated non-ATS transactions from the same stream. The output attribute is a function of the upstream input attribute (if provided), replaced by STE overrides (where configured); this can be evaluated at the time of the Translation Request and encoded into the returned Translated Address as per section 13.6.2 ATS attributes overview. 13.6.5 Split-stage ATS skipping stage 1 Where all of the following are true, a Translation Request without a PASID is configured to skip stage 1 translation, but the ATS configuration is for stage 1-only: • STE.Config[1:0] == 0b11 (Stage 1 and 2 translation enabled) • STE.EATS == 0b10 (Split-stage ATS enabled) • STE.S1CDMax > 0 (Substreams/PASIDs enabled) • STE.S1DSS == 0b01, (non-PASID transactions bypass stage 1) The Translation Request might lead to a fault or configuration error that triggers an ATS response as described in section 3.9.1.2 Responses to ATS Translation Requests. Note: Even if stage 1 is effectively bypassed, a stage 1 Address Size Fault might occur if the input address supplied in the Translation Request is greater than the IAS. ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1096

Chapter 13. Attribute Transformation 13.6. PCIe and ATS attribute/permissions handling Note: A Permission fault leads to one or more of R, W and X permissions being denied in the response, as shown in the next paragraph. Where a Translation Request with a Split-stage ATS configuration skips stage 1, the Translation Request supplies an IPA address and, if a fault or configuration error does not occur, an identity-mapped Translation Completion is returned, which contains: • U == 0 • R and W permissions are granted from the stage 2 permissions for the IPA, with respect to the permissions requested in the Translation Request. • TranslatedAddress 1:1/identity-mapped with the Unstranslated Address of the Translation request. • The maximum permissible translation size is that of the stage 2 translation. Arm recommends that, for performance reasons, the maximum translation size is returned where possible. • Note: See 13.6.4 Full ATS skipping stage 1; this response is made with Execute_Permitted and Privileged_Mode_Access both 0 as it is in response to a request made without a PASID. If the SMMU supports the encoding of attributes into ATS (see 13.6.2 ATS attributes overview), an attribute is returned that causes the resulting ATS Translated transaction to have a final output (after Stage 2 translation in the SMMU) equivalent to the upstream input attribute (if provided), replaced by STE overrides (where configured), combined with the attributes configured in Stage 2 translation. This does not account for the effect of No_snoop, see section 13.6.2.1 Supporting No_snoop with ATS. Note: If SMMU_IDR3.MTCOMB is 1, then the ATS attributes supplied with a Translated transaction are always Combined with Stage 2 attributes. The function then performs Translated accesses with IPAs and these are translated stage 2-only in the same way as described above for Split-stage ATS that does not skip stage 1. ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1097

Chapter 13. Attribute Transformation 13.7. PCIe permission attribute interpretation 13.7 PCIe permission attribute interpretation PCIe-domain permissions are interpreted by the SMMU as described in this section. Base PCIe interconnect expresses only a Read/Write access permission. The PASID TLP prefix adds the following access permissions: • Execute (In the PASID, Execute_Requested, hereafter referred to as ‘Exe’) • Privileged (In the PASID, Privileged_Mode_Requested, hereafter referred to as ‘Priv’) For normal transactions, the SMMU can use R/W and Privileged directly as incoming R/W and PRIV attributes. Note: The PASID TLP prefix can only encode an ‘Execute’ attribute for Memory Read Requests; this is compatible with the SMMU’s behavior in considering all write transactions to be Data. The SMMU interprets the INST and PRIV attributes of a normal transaction without a PASID TLP prefix as “Data” and “Unprivileged”, respectively. For an ATS Translation Request, base PCIe supplies: • Read access is implied in all ATS Translation Requests – An ATS Translation Completion might grant per-page Read access, depending on page permissions. • No-Write (NW) – NW == 0 signals the intention of the device to perform write accesses. When NW == 0, the Translation Completion sent by the SMMU grants Write permission if the page is currently marked as either: * Writable-dirty. * Writable-clean if HTTU is enabled. – When NW == 1, Write permission is permitted but not required to be granted if the page is already marked as writable-dirty. – If HTTU is not enabled, Write permission is not granted when the page is marked as writable-clean. – When HTTU is enabled, a request having NW == 0 to a page marked writable-clean updates the page to be marked Dirty and then grants Write permission in the response. See 3.13.7 ATS, PRI and translation table flag update. Note: Referring to the above, a request with NW == 1 might grant write access if the page is already marked Dirty (as the page permissions contain write permission). – HTTU does not mark a page Dirty in response to a Translation Request with NW == 1. The PASID TLP prefix adds the following to an ATS Translation Request: • Execute (Exe) – This flag requests execute permission. If this flag is set, the response might grant execute permission. The response must not grant execute permission if this flag is not set in the request. A valid translation might or might not grant the requested Execute permission, depending on actual page ‘X’ permission. Note: A request might be made with Exe == 1 and NW == 0, meaning an endpoint requests access for write and execute. This does not imply that the endpoint will perform ‘instruction writes’ to the page. – Exe implies R in an ATS response. Certain configurations of VMSAv8-64 translation tables allow an ‘XO’ execute-only permission. A translation that requests Exe permission through ATS is not compatible with an XO page and will result in no access, unless STE.INSTCFG == Instruction. Similarly, care must be taken when using the Stage 2 ‘XO’ permission with ATS; a guest might map all executable pages as RX but a hypervisor Stage 2 can further modify this down to execute-only. See section 13.7.1 Permission attributes granted in ATS Translation Completions below for more information on ATS Exe permission. • Privileged (Priv) ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1098

Chapter 13. Attribute Transformation 13.7. PCIe permission attribute interpretation – This flag marks the request as being made from a privileged or unprivileged entity in the endpoint. The Priv flag in an ATS Translation Completion Data Entry has the same value as the Priv flag provided with the corresponding ATS Translation Request and the entry contains permissions granted only to that entity/privilege level. Note: The PCIe Specification [1] states: “The ATC must not assume any correlation between the Privileged Mode and Unprivileged Mode permissions associated with a translation.” For an ATS Translation Request without a PASID TLP prefix, the INST and PRIV attributes are treated by the SMMU as “Data” and “Unprivileged”, respectively. Translated transactions that do not have a PASID TLP prefix are treated by the SMMU as “Data”, “Unprivileged”. This applies to all of the following: • Implementations with SMMU_IDR3.PASIDTT == 0. • Implementations with SMMU_IDR3.PASIDTT == 1, and the Translated transaction does not have a PASID TLP prefix. The SMMU uses incoming Priv and Exe attributes if provided in the PASID TLP prefix if SMMU_IDR3.PASIDTT == 1. The following table of example ATS Translation Requests shows the access permissions granted for the request on several different page permission combinations: Example Request Page permissions Response NW == 1, Exe == 0, Priv == 0 User-RO, Priv-RW, XN == 0 R == 1, W == 0, Exe == 0, Priv == 0 NW == 0, Exe == 0, Priv == 0 User-RW, Priv-RW, XN == 0 R == 1, W == 1, Exe == 0, Priv == 0 NW == 0, Exe == 0, Priv == 0 User-RO, Priv-RW, XN == 0 R == 1, W == 0, Exe == 0, Priv == 0 NW == 0, Exe == 0, Priv == 1 User-RO, Priv-RW, XN == 0 R == 1, W == 1, Exe == 0, Priv == 1 NW == 1, Exe == 1, Priv == 0 User-RW, Priv-RW, XN == 1 R == 1, W == 0 or 1, Exe == 0, Priv == 0 Note: The SMMU is permitted to return Write permission if the page is writable, even if NW == 1. NW == 0, Exe == 0, Priv == 0 User-RW, Priv-RW, XN == 1 R == 1, W == 1, Exe == 0, Priv == 0 NW == 0, Exe == 1, Priv == 0 User-RW, Priv-RW, XN == 0 R == 1, W == 1, Exe == 1, Priv == 0 NW == 0, Exe == 1, Priv == 0 User-X, Priv-RW, UXN == 0 (AArch64) R == 0, W == 0, Exe == 0, Priv == 0 NW == any, Exe == any, Priv ==p Translation-related fault R == 0, W == 0, Exe == 0, Priv == p Note: See 3.9.1 ATS Interface; this Translation Completion is marked with ‘Success’ status, as opposed to UR/CA. When the STE.INSTCFG and STE.PRIVCFG override fields are supported (SMMU_IDR1.ATTR_PERMS_OVR == 1), they affect ATS Translation Requests as described in 13.7.1 Permission attributes granted in ATS Translation Completions below. Note: Arm recommends that an STE does not override INST and PRIV when the system supports PCIe PASID prefixes, in order for this attribute to be communicated from the device to the SMMU translation lookup. However, when a PASID TLP prefix is not used and the INST and PRIV attributes are treated by the SMMU as “Data” and “Unprivileged”, as required above, software might override these attributes using the STE input overrides. For example, it might configure a stream to be privileged. When PASIDs/SubstreamIDs are configured for a translating Stage 1 configuration, traffic without a PASID is deemed unexpected if STE.S1DSS == 0b00, and ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1099

Chapter 13. Attribute Transformation 13.7. PCIe permission attribute interpretation aborted. If STE.S1DSS == 0b01, traffic without a PASID skips Stage 1 and translation behaves as though the STE is configured for Stage 2-only translation. In this case, the PRIV attribute is ignored by Stage 2 and the “Data” default is sensible. When HTTU is in use, an ATS TR that generates a response with R == 1 || W == 1 || Exe == 1 also sets the AF flag in the descriptor to 1. When HTTU is enabled for dirty state update (using HD flags), an ATS TR having NW == 0 to a writable-clean page accessible at the requested permission level (permissions are read-only, with DBM == 1 when using the Direct Permission Scheme) will make the page permissions read/write (writable-dirty) and generates a response with W == 1. An ATS TR having NW == 1 must not mark a page as writable-dirty. Note: TTW in nested stage 1+stage 2 scenarios might cause stage 2 pages to be marked writable-dirty where Stage 1 translation table descriptors are updated. Note: As STE.{INSTCFG,PRIVCFG} overrides might affect the permissions granted in an ATS response, a change to these overrides must be accompanied by an invalidation of associated ATCs. Note: When Split-stage ATS is in use, stage 2 translation is performed on incoming Translated transactions. A Translated transaction in implementations with SMMU_IDR3.PASIDTT == 0 from PCIe is treated as Data, Unprivileged. This means that for such implementations, it is possible to configure stage 2 execute permissions so that the ATS Translation Request succeeds, but the subsequent Translated transactions not permitted. For example: 1. A Split-stage ATS Translation Request from a stream with STE.INSTCFG == Instruction is made to an address where stage 1 has RWX permissions and stage 2 has Privileged-XO permissions. 2. The ATS Translation Request succeeds because the combined stage 1+2 permission is Privileged-XO and the STE.INSTCFG configuration treats all accesses as execute. 3. The Translated transaction is translated at stage 2, but is treated by the SMMU as Unprivileged, which causes a stage 2 permission fault. It is IMPLEMENTATION DEFINED whether STE.{INSTCFG, PRIVCFG} override fields affect an ATS Translated transaction when SMMU_(R_)CR0.ATSCHK == 1 for a stream configured with STE.EATS == 0bx1. Arm recommends that an SMMU implementation applies the override fields to Translated transactions in the same manner as for Translation Requests. For an ATS Translated transaction issued by a StreamID configured with STE.EATS == 0b10, the overrides that are configured in STE.INSTCFG and STE.PRIVCFG are applied to the Translated transaction prior to stage 2 translation and permission checking. Note: PRIVCFG only affects stage 2 permission checking if SMMU_IDR3.XNX == 1. Note: Use of Split-stage ATS with STE.INSTCFG, or stage 2 permissions that are not expressible in PCIe, can lead to unexpected results. Arm recommends that STE.INSTCFG is not used with ATS. The PM attribute is not supported on a PCIe interconnect, however an embedded endpoint that supports ATS might be integrated in a way that provides the PM attribute on transactions and Translation requests. See section 3.25.10.1.1 Protected Mode. 13.7.1 Permission attributes granted in ATS Translation Completions The pseudocode below illustrates how the R, W, Exec, Priv attributes in a Translation Completion are calculated with respect to the input Translation Request, the translation table descriptor permissions and the STE INSTCFG/PRIVCFG overrides. A PRIVCFG == Privileged or PRIVCFG == Unprivileged override calculates (R,W,X) attributes appropriate to the privilege level to which the request was overridden, but the ‘Priv’ field in the ATS Translation Completion returns the same privilege supplied in the associated Translation Request. • For example, a TR with ‘NW == 0, Exe == 0, Priv == 1’ with PRIVCFG == Unprivileged, and page permissions of ‘User-RO, Priv-RW’, returns a Translation Completion with ‘R == 1, W == 0, Exe == 0, Priv == 1’. The INSTCFG override affects the interpretation of the TR’s Exe and the translation table ‘X’ attributes. ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1100

Chapter 13. Attribute Transformation 13.7. PCIe permission attribute interpretation // Here, TR is the incoming Translation Request, TC is the returned // Translation Completion and final_combined_translation is the // result of all enabled stages of translation for the given address. // HTTU is not shown; it is assumed final_combined_translation contains // post-HTTU permissions if relevant. (Note: HTTU for ATS is influenced // by TR.NW.) if (!TR.PASID_present) { // The Priv and Exe fields of a Translation Completion without a // PASID are Reserved and set to 0. Effectively, there are no Priv // and Exe permission bits in a response without a PASID: TR.Priv = 0; TR.Exe = 0; } // The Translation Completion's Priv field is not affected by PRIVCFG and // is as the TR supplied: TC.Priv = TR.Priv; STE_effective_PRIVCFG = (SMMU_IDR1.ATTR_PERMS_OVR == 1) ? STE.PRIVCFG : Use_Incoming; STE_effective_INSTCFG = (SMMU_IDR1.ATTR_PERMS_OVR == 1) ? STE.INSTCFG : Use_Incoming; // Effective privilege that permissions will be checked against: effectivePriv = (STE_effective_PRIVCFG == Use_Incoming) ? TR.Priv : ((STE_effective_PRIVCFG == PRIVILEGED) ? 1 : 0)); ttd_R = final_combined_translation.readable_by_privlevel(effectivePriv); ttd_RX = ttd_R && final_combined_translation.executable_by_privlevel(effectivePriv); ttd_X = final_combined_translation.executable_by_privlevel(effectivePriv); // Grant of write permission is always governed by the translation's W // permission. Also note that, when enabled, HTTU only sets Dirty if // TR.NW == 0; the page is writable if this is the case, or if the page is // already Dirty (see text). // Note: An implementation is not required to return W == 1 if // TR.NW == 1 and translation table descriptor permissions include write, // but doing so can avoid the Endpoint having to make a second request if it // subsequently requires to write. TC.W = final_combined_translation.writable_by_privlevel(effectivePriv); if (STE_effective_INSTCFG == Use_Incoming) { TC.R = ttd_R; TC.Exe = TR.Exe && ttd_RX; // Granting X implies granting R // Note: An execute-only (XO) translation grants no access to ATS. // A normal (non-ATS) transaction for Exe == 1 will succeed // to an XO translation. } else if (STE_effective_INSTCFG == INST) { TC.R = ttd_X; TC.Exe = TR.Exe && ttd_X; // Note: An XO translation can grant R&Exe access to an ATS Request // because in this configuration all reads are considered // instruction fetches, therefore R&Exe are the same. } else { // STE.INSTCFG == DATA // This is effectively equivalent to assuming X=R; anything with 'R' // for the privilege level is accessible. TC.R = ttd_R; TC.Exe = TR.Exe && ttd_R; } ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1101

Chapter 13. Attribute Transformation 13.8. Attributes for SMMU-originated accesses 13.8 Attributes for SMMU-originated accesses This table provides a summary of memory attributes used for SMMU-originated accesses. This table is an informative summary of the fields used to determine the memory attributes and the normative requirements are captured in the register and structure fields referenced. Access Attributes determined by STE fetch SMMU_()CR1.{TABLE_IC, TABLE_OC, TABLE_SH} VMS fetch SMMU()CR1.{TABLE_IC, TABLE_OC, TABLE_SH} CD fetch STE.{S1CIR, S1COR, S1CSH}, combined with stage 2 attributes if stage 2 translation is enabled, including the effects of STE.S2FWB and STE.S2PTW. Stage 1 walk CD.{IRx, ORx, SHx}, combined with stage 2 attributes if stage 2 translation is enabled, including the effects of STE.S2FWB and STE.S2PTW. Stage 2 walk STE.{S2IR0, S2OR0, S2SH0} GPT walk SMMU_ROOT_GPT_BASE_CFG.{IRGN, ORGN, SH} DPT walk SMMU(R_)CR1.{TABLE_IC, TABLE_OC, TABLE_SH} SID translation walk SMMU_(R_)CR1.{QUEUE_IC, QUEUE_OC, QUEUE_SH} See section 3.5.9.2 Attributes used during vSID translation. GERROR MSI SMMU_()GERROR_IRQ_CFG2.{MemAttr, SH} EVENTQ MSI SMMU()EVENTQ_IRQ_CFG2.{MemAttr, SH} PRIQ MSI SMMU_PRIQ_IRQ_CFG2.{MemAttr, SH} CMDQ MSI CMD_SYNC.{MSIAttr, MSH} CMDQ fetch SMMU()CR1.{QUEUE_IC, QUEUE_OC, QUEUE_SH} and SMMU()CMDQ_BASE.RA ECMDQ MSI CMD_SYNC.{MSIAttr, MSH} ECMDQ fetch SMMU()CR1.{QUEUE_IC, QUEUE_OC, QUEUE_SH} and SMMU()ECMDQ_BASEn.RA DCMDQ MSI CMD_SYNC.{MSIAttr, MSH}. See section 3.5.7.4 DCMDQ Attributes. DCMDQ fetch Normal-iWB-oWB-iSH and SMMU()DCMDQ_BASEn.RA. See section 3.5.7.4 DCMDQ Attributes. PRIQ write SMMU(R_)CR1.{QUEUE_IC, QUEUE_OC, QUEUE_SH} and SMMU_(R_)PRIQ_BASE.WA EVENTQ write SMMU_()CR1.{QUEUE_IC, QUEUE_OC, QUEUE_SH} and SMMU()EVENTQ_BASE.WA HDBSS access SMMU()CR1.{QUEUE_IC, QUEUE_OC, QUEUE_SH}. See section 3.13.9.1 HDBSS Table updates. HACDBS access SMMU(*_)CR1.{QUEUE_IC, QUEUE_OC, QUEUE_SH}. See section 3.13.10.1 HACDBS Processing. PBHA values used for SMMU-originated accesses are as follows: • For GPT lookups and DPT lookups, PBHA values assigned are consistent with PBHA being disabled or not implemented. ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1102

Chapter 13. Attribute Transformation 13.8. Attributes for SMMU-originated accesses • For all other SMMU-originated accesses, PBHA values assigned are IMPLEMENTATION DEFINED. ARM IHI 0070 H.a Copyright © 2016-2026 Arm Limited or its affiliates. All rights reserved. Non-confidential 1103