Thread (21 messages) flat view 21 messages, 5 authors, 2017-03-23
STALE3424d

[PATCH v2 4/5] iommu/arm-smmu-v3: Install bypass STEs for IOMMU_DOMAIN_IDENTITY domains

From: robin.murphy@arm.com (Robin Murphy)
Date: 2017-03-21 17:33:52
Also in: linux-iommu

On 21/03/17 17:08, Will Deacon wrote:
Hi Robin,

On Thu, Mar 16, 2017 at 06:19:48PM +0000, Robin Murphy wrote:
quoted
On 16/03/17 16:24, Nate Watterson wrote:
quoted
On 2017-03-10 15:49, Will Deacon wrote:
quoted
In preparation for allowing the default domain type to be overridden,
this patch adds support for IOMMU_DOMAIN_IDENTITY domains to the
ARM SMMUv3 driver.

An identity domain is created by placing the corresponding stream table
entries into "bypass" mode, which allows transactions to flow through
the SMMU without any translation.
What about masters that require SMMU intervention to override their
native memory attributes to make them consistent with the CCA (acpi)
or dma-coherent (dt) values specified in FW?
Well, we've already broken them ;) My interpretation of "dma-coherent"
is as the equivalent of DACS=1,CPM=1, i.e. not dependent on SMMU
override. For the CCA=1,DACS=0 case (I'm going to pretend the DT
equivalent will never exist...) the first problem to solve is how to
inherit the appropriate configuration from the firmware, because right
now we're not even pretending to support that.
Indeed, and that would need to be added as a separate patch series when
the need arises.
quoted
quoted
quoted
     /* Nuke the existing STE_0 value, as we're going to rewrite it */
-    val = ste->valid ? STRTAB_STE_0_V : 0;
+    val = STRTAB_STE_0_V;
+
+    /* Bypass/fault */
+    if (!ste->assigned || !(ste->s1_cfg || ste->s2_cfg)) {
+        if (!ste->assigned && disable_bypass)
...yuck. After about 5 minutes of staring at that, I've convinced myself
that it would make much more sense to always clear the strtab_ent
configs on detach, such that you never need the outer !ste->assigned
check here...
I was deliberately keeping the strtab_ent intact in case we ever grow
support for nested translation, where we might well want to detach a
stage 1 but keep the stage 2 installed. I don't think the code is that
bad, so I'd like to leave it like it is for now.
Sure, it would certainly be more awkward to recreate this logic from
scratch in future if we need it again. I suggested the cleanup since it
looked like an oversight, but if it's a conscious decision then that's
fine by me.

Robin.
Will
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help