Anonymous user
ARM SMMU versions 1 and 2: Difference between revisions
m
Categorize
| [unchecked revision] | [unchecked revision] |
m (Categorize) |
|||
| (28 intermediate revisions by the same user not shown) | |||
Line 4:
A common 's' in a register name, as in SMMU_sCR0 implies that versions of this register exist for both secure and non-secure mode and that both versions are being talked about in that instance.
The SMMU supports processing transactions from multiple streams at once, and translation of multiple contexts at once.
== Terminology: ==
Line 46 ⟶ 48:
** When the SSD space is present in the SMMU, the SMMU_SSDRn registers are present.
** These SMMU_SSDRn registers are bitfields, 32 bits each. If bit<N> is 1 then device<N> is non-secure, else it is secure.
==== Splitting the Stream Mapping table between secure and non-secure mode ====
The Stream Mapping table is global and shared between Secure and non-secure mode. Secure mode must decide how many Stream Mapping register groups it will expose for non-secure mode's use. ARM recommends that secure mode software leaves at least one Stream mapping register group for use by non-secure software.
Having an SMMU_S2CR which has been allocated to secure be configured to mode point to a context bank which is non-secure is UNPREDICTABLE. Having an SMMU_S2CR which has been allocated to non-secure mode be configured to point to a context bank which is secure will trigger an Unimplemented Context Bank SMMU Fault
==== Splitting the Context banks between secure and non-secure mode ====
Some number of context banks can be reserved for use by secure mode using SMMU_SCR1.NSNUMCBO. The allocation begins from the top of the available context bank space. The SMMU will intelligently present the correct number of context banks to non-secure mode through non-secure accesses to SMMU_IDR1.NUMCB. '' SMMU_SCR1.NSNUMCBO actually reserves a number of context banks for '''non-secure''' mode. The leftover context banks that come '''after''' those reserved by SMMU_SCR1.NSNUMCBO are what are actually reserved for '''secure''' mode. ''.
=== Translation, bypass and faulting ===
Line 63 ⟶ 71:
The SSD register space, if available, tells the OS which devices are secure vs non-secure. For a secure-mode OS, it allows the OS to set which StreamIDs are secure/non-secure. A Secure-mode OS should set these registers up. A non-secure mode OS may choose to read these registers to determine which devices are under its purvue.
Also, secure mode software may need to prevent access by non-secure software to the global register file of the SMMU. This can be done by setting SMMU_SCR1.GASRAE==1 (Section 2.10.1).
=== StreamIDs ===
Line 86 ⟶ 96:
* Support for Stream Matching is indicated via SMMU_IDR0.SMS == 1.
* Support for Extended Stream Matching is indicated via SMMU_IDR0.EXSMRGS == 1.
* Enable Extended Stream Matching using SMMU_sCR2.EXSMRGENABLE==1.
** Setting SMMU_SCR2.EXNSSMRGDISABLE==1 with a secure write to SMMU_SCR2 disables the use of Extended Stream Matching by non-secure mode.
* Support for compressed Indexing (which is a subfeature under Stream Matching) is indicated via a secure read of SMMU_IDR2.COMPINDEXS == 1. A non-secure read of this bit only states whether or not compressed indexing is available for use by non-secure software.
* The number of Stream Mapping Register Groups is determined by reading SMMU_IDR0.NUMSMRG.
Line 93 ⟶ 105:
''ARM found it important to mention that if the SMMU support Extended Stream Matching and the extension is not enabled, the (up to) 128 SMMU_SMRs that are exposed, map onto the final 128 SMMU_SMRs provided by the extension. Since it's apparently important, I'll mention it too.''
===
The max number of supported contexts is implied by the max number of
* Multiple SMMU_SMRn regs may cause multiple StreamIDs to map to the same Context when Stream Matching is used.
* Each incoming StreamID maps directly to a specific Context when Stream Indexing is used.
Section 2.6.1: '' On reset no translation context bank table entry initializatoin is required. Typically, the SMMU implementation [sic] initializes the required values before use. ''
=== Support for stage1 and stage2 ===
Line 106 ⟶ 120:
* Support for stage1 followed by stage2 translation is indicated via SMMU_IDR0.NTS.
** If SMMU_IDR0.NTS is set, then both SMMU_IDR0.S1TS and SMMU_IDR0.S2TS must be set.
If both stage1 and stage2 are supported, then all contexts except the first X can support either stage1 or stage2 translation. The first X context banks '''may''' be restricted such that they only support stage2. To detect the number X which can only be used for stage2 translation, see SMMU_IDR1.NUMS2CB. The SMMU_CBARn.TYPE field governs the stage of translation for a context bank which supports both stages.
=== Stream Mapping Table ===
Line 174 ⟶ 190:
The SMMU is allowed to prefetch the translation tables pointed to by a context bank if that context bank is pointed to by an entry in the Stream Mapping table. This is permitted even if there is no client transaction which is using/ has used that translation (section 2.5.1).
=== TLB Maintenance ===
==== HYPC contexts ====
Section 2.8.2: ''TLB entries that are allocated as a result of HYPC accesses are Hyp tagged. All HYP tagged TLB entries are considered to belong to the same software entity and have no associated ASID or VMID.''
Ergo the SMMU assumes that there is only one piece of software that is acting as a hypervisor.
==== MONC contexts (Section 2.9.2) ====
SMMUv2 provides the following TLB maintenance operations for maintaining MONC TLB tagged entries:
* SMMU_TLBIALLM: Invalidate all EL3 Monitor entries.
* SMMU_TLBIVAM: Invalidates all EL3 Monitor entries which are associated with a 64-bit VA.
* SMMU_TLBIVALM: Same as TLBIVAM, but invalidates only the last level table entries.
ARM found it necessary to warn that: ''These operations are not required to invalidate non-MONC Secure TLB entries''.
==== E2HC contexts (Section 2.10) ====
E2HC context TLB entries are tagged by the TLB as E2H, but have no security state tagging. They are coupled with an ASID if they are non-global.
TLB entries for E2HC contexts matching combinations of (E2H identification) or (E2H identification+ASID tagging) are required to be invalidated by:
* SMMU_TLBIALLH
* SMMU_TLBIVAH
* SMMU_TLBIVAH64
* SMMU_TLBIVALH64
* SMMU_TLBIALLNSNH
E2H identified TLB entries are not required to be invalidated by:
* Secure TLBI operations.
* SMMU_TLBIVMID.
* SMMU_TLBIVMIDS1
Additionally, the standard SMMU_CBn_TLBI* operations work on E2HC context TLB entries, except that instead of matching based on VMID, they match based on (E2H identification) or (E2H identification + ASID tagging).
In particular '''other than the specific TLB invalidate operations bulleted above, E2HC contexts are not considered to be hypervisor contexts by the SMMU'''.
Operation of the TLB is UNPREDICTABLE if there exist TLB entries allocated in the cache identified as HYPC and E2HC concurrently. Software must invalidate the HYPC/E2HC TLBs when switching between operating the SMMU with E2HC vs HYPC support enabled. Please see Section 2.10, example 2-1 for a full listing of the procedure for enabling E2HC operation.
== Context banks ==
Each context bank is one page large, where "one page" is defined as PAGESIZE which may be either 4KiB or 64KiB. The intention is that a hypervisor can
Accessing an unimplemented context bank's register space will either result in an IMPLEMENTATION DEFINED result of either RAZ/WI or a Configuration Access SMMU Fault.
The SMMU_CBA2Rn.MONC, SMMU_CBARn.HYPC and SMMU_CBA2Rn.VA64 bits work together to define the security context and page table format (long vs short) for translation of a particular context bank.
=== Hypervisor Contexts (HYPC) (section 2.8) ===
Hypervisor mode contexts (HYPC) are the page tables of an OS running in HYP mode and not the 2nd stage page tables for a guest IPA. The SMMU is able to walk HYPC page tables. For that reason a HYPC bank cannot be a stage1 followed by stage2 context. I couldn't think of a good reason for a normal hypervisor to prefer to use HYPC tables when it can just use normal IO page tables. '''I could also be misinterpreting the purpose of this feature''', as it appears to be linked to VHE extensions, and it may pertain to a special page table format used by VHE guests.
Support for HYPC is mututally exclusive with support for E2HC. HYPC is supported:
* For both SMMUv1 and SMMUv2, if VHE is not supported, then HYPC is supported.
* In an SMMUv2 implementation that has VHE, if SMMU_CR0.HYPMODE==0, HYPC is available, else E2HC is available.
VHE is supported by the SMMU if:
* SMMU_IDR2.E2HS==1
To set a context bank to be a HYPC bank, set SMMU_CBARn.HYPC==1.
Caveats:
* Do not set the HYPC bit on '''secure''' context banks -- that's illogical. See section 2.8.3 for details.
* The SMMU_CBn_TCR2.SEP field is ignored for HYPC contexts.
=== Monitor Contexts (MONC) (Section 2.9) ===
I couldn't determine whether MONC contexts are meant for use by devices claimed specifically by Monitor Mode (EL3) or whether this bit is meant to be set by all secure mode software. The specific wording of the manual is:
Section 2.9: ''In SMMUv2, '''for a secure bank''', when the value of the corresponding SMMU_CBA2Rn.MONC bit is 1, the bank is a MONC (Secure Monitor) context bank. MONC Translation context banks are intended to be used by the Secure EL3 translation regime.''
The phrasing seems to support the latter of the two interpretations.
Caveats:
* Do not set both HYPC and MONC on any bank because that is UNPREDICTABLE.
* MONC only pertains to contexts reserved for secure mode use. Non-secure contexts ignore and treat the MONC bit as 0. Set it to 0.
* Sign extension via SMMU_CBn_TCR2.SEP is ignored for MONC banks.
=== VHE EL2 Contexts (E2HC) (Section 2.10) ===
E2HC contexts are meant to be used by hypervisor guests running in pseudo-EL2 (ARM's VHE feature) on top of another hypervisor which is running in real-EL2. The SMMU can only be programmed to use either E2HC or HYPC, but not both at the same time. This is a decision which must be made globally and it affects all software using the SMMU whether secure or nonsecure, whether EL3, EL2 or EL1. In fact, the HYPC and E2HC bits are polymorphically at the same position in the register.
E2HC contexts must be programmed to be of SMMU_CBARn.TYPE of 0b01 (stage1 followed by stage2 bypass). Unlike HYPC however, the E2HC translation regime is split between two TTBR registers. See the TLB management section to understand how the TLB entries for E2HC are handled by the TLB.
== IRQs / SMMU Faults ==
=== Context bank faults ===
The SMMU may raise faults for a context bank when processing a stage of translation for a particular context bank.
* For SMMUv1, the SMMU_CBAR register states which interrupt is raised to signal faults while processing that context.
* For SMMUv2, each context bank has its own IRQ pin.
[[Category:ARM]]
| |||