Anonymous user
ARM SMMU versions 1 and 2: Difference between revisions
m
Categorize
| [unchecked revision] | [unchecked revision] |
m (→Context banks) |
m (Categorize) |
||
| (15 intermediate revisions by the same user not shown) | |||
Line 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 94 ⟶ 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 186 ⟶ 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 ==
Line 193 ⟶ 236:
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 ==
Line 201 ⟶ 279:
* 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]]
| |||