From: Will Deacon <hidden> Date: 2017-03-10 20:49:31
Hi all,
This is version two of the patches previously posted here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/481275.html
I've addressed the review feedback I receive there, but the main change
is that the SMMUv3 driver now handles passthrough domains independently
of the disable_bypass parameter.
All feedback welcome,
Will
--->8
Will Deacon (5):
iommu/arm-smmu: Restrict domain attributes to UNMANAGED domains
iommu/arm-smmu: Install bypass S2CRs for IOMMU_DOMAIN_IDENTITY domains
iommu/arm-smmu-v3: Make arm_smmu_install_ste_for_dev return void
iommu/arm-smmu-v3: Install bypass STEs for IOMMU_DOMAIN_IDENTITY
domains
iommu: Allow default domain type to be set on the kernel command line
Documentation/admin-guide/kernel-parameters.txt | 6 ++
drivers/iommu/arm-smmu-v3.c | 76 +++++++++++++++----------
drivers/iommu/arm-smmu.c | 26 ++++++++-
drivers/iommu/iommu.c | 17 +++++-
4 files changed, 90 insertions(+), 35 deletions(-)
--
2.1.4
From: Will Deacon <hidden> Date: 2017-03-10 20:49:32
The ARM SMMU drivers provide a DOMAIN_ATTR_NESTING domain attribute,
which allows callers of the IOMMU API to request that the page table
for a domain is installed at stage-2, if supported by the hardware.
Since setting this attribute only makes sense for UNMANAGED domains,
this patch returns -ENODEV if the domain_{get,set}_attr operations are
called on other domain types.
Signed-off-by: Will Deacon <redacted>
---
drivers/iommu/arm-smmu-v3.c | 6 ++++++
drivers/iommu/arm-smmu.c | 6 ++++++
2 files changed, 12 insertions(+)
From: Will Deacon <hidden> Date: 2017-03-10 20:49:33
In preparation for allowing the default domain type to be overridden,
this patch adds support for IOMMU_DOMAIN_IDENTITY domains to the
ARM SMMU driver.
An identity domain is created by placing the corresponding S2CR
registers into "bypass" mode, which allows transactions to flow through
the SMMU without any translation.
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Will Deacon <redacted>
---
drivers/iommu/arm-smmu.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
From: Will Deacon <hidden> Date: 2017-03-10 20:49:34
arm_smmu_install_ste_for_dev cannot fail and always returns 0, however
the fact that it returns int means that callers end up implementing
redundant error handling code which complicates STE tracking and is
never executed.
This patch changes the return type of arm_smmu_install_ste_for_dev
to avoid, to make it explicit that it cannot fail.
Signed-off-by: Will Deacon <redacted>
---
drivers/iommu/arm-smmu-v3.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
From: Will Deacon <hidden> Date: 2017-03-10 20:49:35
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.
Signed-off-by: Will Deacon <redacted>
---
drivers/iommu/arm-smmu-v3.c | 58 +++++++++++++++++++++++++++++----------------
1 file changed, 37 insertions(+), 21 deletions(-)
@@ -1509,6 +1518,11 @@ static int arm_smmu_domain_finalise(struct iommu_domain *domain)structarm_smmu_domain*smmu_domain=to_smmu_domain(domain);structarm_smmu_device*smmu=smmu_domain->smmu;+if(domain->type==IOMMU_DOMAIN_IDENTITY){+smmu_domain->stage=ARM_SMMU_DOMAIN_BYPASS;+return0;+}+/* Restrict the stage to what we can actually support */if(!(smmu->features&ARM_SMMU_FEAT_TRANS_S1))smmu_domain->stage=ARM_SMMU_DOMAIN_S2;
@@ -1617,7 +1631,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)ste=&master->ste;/* Already attached to a different domain? */-if(!ste->bypass)+if(ste->assigned)arm_smmu_detach_dev(dev);mutex_lock(&smmu_domain->init_mutex);
From: Will Deacon <hidden> Date: 2017-03-10 20:49:36
The IOMMU core currently initialises the default domain for each group
to IOMMU_DOMAIN_DMA, under the assumption that devices will use
IOMMU-backed DMA ops by default. However, in some cases it is desirable
for the DMA ops to bypass the IOMMU for performance reasons, reserving
use of translation for subsystems such as VFIO that require it for
enforcing device isolation.
Rather than modify each IOMMU driver to provide different semantics for
DMA domains, instead we introduce a command line parameter that can be
used to change the type of the default domain. Passthrough can then be
specified using "iommu.passthrough=1" on the kernel command line.
Signed-off-by: Will Deacon <redacted>
---
Documentation/admin-guide/kernel-parameters.txt | 6 ++++++
drivers/iommu/iommu.c | 17 +++++++++++++++--
2 files changed, 21 insertions(+), 2 deletions(-)
@@ -1635,6 +1635,12 @@ nobypass [PPC/POWERNV] Disable IOMMU bypass, using IOMMU for PCI devices.+ iommu.passthrough=+ [ARM64] Configure DMA to bypass the IOMMU by default.+ Format: { "0" | "1" }+ 0 - Use IOMMU translation for DMA.+ 1 - Bypass the IOMMU for DMA.+ unset - Use IOMMU translation for DMA. io7= [HW] IO7 for Marvel based alpha systems See comment before marvel_specify_io7 in
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? To make sure those cases
are handled, you could store away the master's coherency setting in
its strtab_ent at attach time and then setup STE[MemAttr/ALLOCCFG/SHCFG]
so the attributes are forced to the correct values while still
bypassing translation.
arm_smmu_device *smmu, u32 sid,
* This is hideously complicated, but we only really care about
* three cases at the moment:
*
- * 1. Invalid (all zero) -> bypass (init)
- * 2. Bypass -> translation (attach)
- * 3. Translation -> bypass (detach)
+ * 1. Invalid (all zero) -> bypass/fault (init)
+ * 2. Bypass/fault -> translation/bypass (attach)
+ * 3. Translation/bypass -> bypass/fault (detach)
*
* Given that we can't update the STE atomically and the SMMU
* doesn't read the thing in a defined order, that leaves us
@@ -1617,7 +1631,7 @@ static int arm_smmu_attach_dev(struct
iommu_domain *domain, struct device *dev)
ste = &master->ste;
/* Already attached to a different domain? */
- if (!ste->bypass)
+ if (ste->assigned)
arm_smmu_detach_dev(dev);
mutex_lock(&smmu_domain->init_mutex);
@@ -1638,10 +1652,12 @@ static int arm_smmu_attach_dev(struct
--
Qualcomm Datacenter Technologies, Inc. on behalf of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux
Foundation Collaborative Project.
arm_smmu_install_ste_for_dev cannot fail and always returns 0, however
the fact that it returns int means that callers end up implementing
redundant error handling code which complicates STE tracking and is
never executed.
This patch changes the return type of arm_smmu_install_ste_for_dev
to avoid, to make it explicit that it cannot fail.
Did you mean "a void" or just "void" instead of "avoid"?
--
Qualcomm Datacenter Technologies, Inc. on behalf of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux
Foundation Collaborative Project.
Hi Nate, Will,
On 16/03/17 16:24, Nate Watterson wrote:
Hi Will,
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.
To make sure those cases
are handled, you could store away the master's coherency setting in
its strtab_ent at attach time and then setup STE[MemAttr/ALLOCCFG/SHCFG]
so the attributes are forced to the correct values while still
bypassing translation.
However, for this particular piece of the puzzle, that does sound about
right - the attribute overrides are pretty much orthogonal to the stage
of translation (or bypass), so the master's strtab_ent will indeed
probably be the most appropriate place to keep them once we get there
(cf. the master's s2cr in SMMUv2).
Now, while I'm here...
arm_smmu_device *smmu, u32 sid,
* This is hideously complicated, but we only really care about
* three cases at the moment:
*
- * 1. Invalid (all zero) -> bypass (init)
- * 2. Bypass -> translation (attach)
- * 3. Translation -> bypass (detach)
+ * 1. Invalid (all zero) -> bypass/fault (init)
+ * 2. Bypass/fault -> translation/bypass (attach)
+ * 3. Translation/bypass -> bypass/fault (detach)
*
* Given that we can't update the STE atomically and the SMMU
* doesn't read the thing in a defined order, that leaves us
arm_smmu_device *smmu, u32 sid,
}
/* 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...
quoted
+ val |= STRTAB_STE_0_CFG_ABORT;
+ else
+ val |= STRTAB_STE_0_CFG_BYPASS;
- if (ste->bypass) {
- val |= disable_bypass ? STRTAB_STE_0_CFG_ABORT
- : STRTAB_STE_0_CFG_BYPASS;
dst[0] = cpu_to_le64(val);
dst[1] = cpu_to_le64(STRTAB_STE_1_SHCFG_INCOMING
<< STRTAB_STE_1_SHCFG_SHIFT);
@@ -1617,7 +1631,7 @@ static int arm_smmu_attach_dev(struct
iommu_domain *domain, struct device *dev)
ste = &master->ste;
/* Already attached to a different domain? */
- if (!ste->bypass)
+ if (ste->assigned)
arm_smmu_detach_dev(dev);
mutex_lock(&smmu_domain->init_mutex);
@@ -1638,10 +1652,12 @@ static int arm_smmu_attach_dev(struct
...or all these explicit NULL assignments (and indeed the entire
ARM_SMMU_DOMAIN_BYPASS case) here. Deliberately keeping potentially
stale context pointers hanging around in unassigned strtab_ents seems
silly (it might trick kmemleak, for another thing).
Robin.
It would be good to have a fall-back here if we are talking to an IOMMU
driver that uses default domains, but does not support identity-mapped
domains (yet). Exynos and Rockchip IOMMU drivers seem to fall into this
category. A dev_warn() also makes sense in case allocating a identity
domain fails.
Joerg
From: Will Deacon <hidden> Date: 2017-03-21 16:42:41
Hi Joerg,
On Tue, Mar 21, 2017 at 04:46:24PM +0100, Joerg Roedel wrote:
On Fri, Mar 10, 2017 at 08:49:31PM +0000, Will Deacon wrote:
quoted
Will Deacon (5):
iommu/arm-smmu: Restrict domain attributes to UNMANAGED domains
iommu/arm-smmu: Install bypass S2CRs for IOMMU_DOMAIN_IDENTITY domains
iommu/arm-smmu-v3: Make arm_smmu_install_ste_for_dev return void
iommu/arm-smmu-v3: Install bypass STEs for IOMMU_DOMAIN_IDENTITY
domains
iommu: Allow default domain type to be set on the kernel command line
Documentation/admin-guide/kernel-parameters.txt | 6 ++
drivers/iommu/arm-smmu-v3.c | 76 +++++++++++++++----------
drivers/iommu/arm-smmu.c | 26 ++++++++-
drivers/iommu/iommu.c | 17 +++++-
4 files changed, 90 insertions(+), 35 deletions(-)
Besides my one comment on the last patch this series looks good to me.
Do you plan to include it (with the fall-back) into your pull-request?
Yes, that would certainly be easiest for me, given the changes to the
SMMU drivers. However, if you prefer it separately then I can do that too.
Cheers,
Will
From: Will Deacon <hidden> Date: 2017-03-21 17:08:16
Hi Robin,
On Thu, Mar 16, 2017 at 06:19:48PM +0000, Robin Murphy wrote:
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
/* 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.
Will
It would be good to have a fall-back here if we are talking to an IOMMU
driver that uses default domains, but does not support identity-mapped
domains (yet). Exynos and Rockchip IOMMU drivers seem to fall into this
category. A dev_warn() also makes sense in case allocating a identity
domain fails.
@@ -1027,10 +1027,19 @@ struct iommu_group *iommu_group_get_for_dev(struct device *dev)*IOMMUdriver.*/if(!group->default_domain){-group->default_domain=-__iommu_domain_alloc(dev->bus,iommu_def_domain_type);+structiommu_domain*dom;++dom=__iommu_domain_alloc(dev->bus,iommu_def_domain_type);+if(!dom){+dev_warn(dev,+"failed to allocate default IOMMU domain of type %u; falling back to IOMMU_DOMAIN_DMA",+iommu_def_domain_type);+dom=__iommu_domain_alloc(dev->bus,IOMMU_DOMAIN_DMA);+}++group->default_domain=dom;if(!group->domain)-group->domain=group->default_domain;+group->domain=dom;}ret=iommu_group_add_device(group,dev);
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.
It would be good to have a fall-back here if we are talking to an IOMMU
driver that uses default domains, but does not support identity-mapped
domains (yet). Exynos and Rockchip IOMMU drivers seem to fall into this
category. A dev_warn() also makes sense in case allocating a identity
domain fails.
@@ -1027,10 +1027,19 @@ struct iommu_group *iommu_group_get_for_dev(struct device *dev)*IOMMUdriver.*/if(!group->default_domain){-group->default_domain=-__iommu_domain_alloc(dev->bus,iommu_def_domain_type);+structiommu_domain*dom;++dom=__iommu_domain_alloc(dev->bus,iommu_def_domain_type);+if(!dom){+dev_warn(dev,+"failed to allocate default IOMMU domain of type %u; falling back to IOMMU_DOMAIN_DMA",+iommu_def_domain_type);
Conversely, that's going to be noisy if iommu_def_domain_type was
IOMMU_DOMAIN_DMA to begin with. I think it makes sense to warn if the
user asked for a specific default domain type on the command line and
that didn't work, but maybe not to bother otherwise. Plus, if they asked
for passthrough, then not allocating a default domain at all is probably
closer to the desired result than installing a DMA ops domain would be.
Robin.
+ dom = __iommu_domain_alloc(dev->bus, IOMMU_DOMAIN_DMA);
+ }
+
+ group->default_domain = dom;
if (!group->domain)
- group->domain = group->default_domain;
+ group->domain = dom;
}
ret = iommu_group_add_device(group, dev);
It would be good to have a fall-back here if we are talking to an IOMMU
driver that uses default domains, but does not support identity-mapped
domains (yet). Exynos and Rockchip IOMMU drivers seem to fall into this
category. A dev_warn() also makes sense in case allocating a identity
domain fails.
@@ -1027,10 +1027,19 @@ struct iommu_group *iommu_group_get_for_dev(struct device *dev)*IOMMUdriver.*/if(!group->default_domain){-group->default_domain=-__iommu_domain_alloc(dev->bus,iommu_def_domain_type);+structiommu_domain*dom;++dom=__iommu_domain_alloc(dev->bus,iommu_def_domain_type);+if(!dom){+dev_warn(dev,+"failed to allocate default IOMMU domain of type %u; falling back to IOMMU_DOMAIN_DMA",+iommu_def_domain_type);
Conversely, that's going to be noisy if iommu_def_domain_type was
IOMMU_DOMAIN_DMA to begin with. I think it makes sense to warn if the
user asked for a specific default domain type on the command line and
that didn't work, but maybe not to bother otherwise. Plus, if they asked
for passthrough, then not allocating a default domain at all is probably
closer to the desired result than installing a DMA ops domain would be.
You're right -- I'll hack this about to check if the default type isn't
DOMAIN_DMA before warning about the allocation failure.
Cheers,
Will
It would be good to have a fall-back here if we are talking to an IOMMU
driver that uses default domains, but does not support identity-mapped
domains (yet). Exynos and Rockchip IOMMU drivers seem to fall into this
category. A dev_warn() also makes sense in case allocating a identity
domain fails.
It would be good to have a fall-back here if we are talking to an IOMMU
driver that uses default domains, but does not support identity-mapped
domains (yet). Exynos and Rockchip IOMMU drivers seem to fall into this
category. A dev_warn() also makes sense in case allocating a identity
domain fails.
@@ -1027,10 +1027,19 @@ struct iommu_group *iommu_group_get_for_dev(struct device *dev)*IOMMUdriver.*/if(!group->default_domain){-group->default_domain=-__iommu_domain_alloc(dev->bus,iommu_def_domain_type);+structiommu_domain*dom;++dom=__iommu_domain_alloc(dev->bus,iommu_def_domain_type);+if(!dom){+dev_warn(dev,+"failed to allocate default IOMMU domain of type %u; falling back to IOMMU_DOMAIN_DMA",+iommu_def_domain_type);
Conversely, that's going to be noisy if iommu_def_domain_type was
IOMMU_DOMAIN_DMA to begin with. I think it makes sense to warn if the
user asked for a specific default domain type on the command line and
that didn't work, but maybe not to bother otherwise. Plus, if they asked
for passthrough, then not allocating a default domain at all is probably
closer to the desired result than installing a DMA ops domain would be.
You're right -- I'll hack this about to check if the default type isn't
DOMAIN_DMA before warning about the allocation failure.
if some master devices want 'IDENTITY_DOMAIN' as default (because those
devices do not want any iommu resources to be used/dma_ops to be set)
and some 'DMA_DOMAIN' as default, then should the default be
'DMA_DOMAIN' and then masters needing IDENTITY_DOMAIN explicitly do an
detach_dev later. This [1] was adding the support for detach_dev
of the default DMA_DOMAINs.
[1] https://patchwork.codeaurora.org/patch/164933/
Regards,
Sricharan
It would be good to have a fall-back here if we are talking to an IOMMU
driver that uses default domains, but does not support identity-mapped
domains (yet). Exynos and Rockchip IOMMU drivers seem to fall into this
category. A dev_warn() also makes sense in case allocating a identity
domain fails.
@@ -1027,10 +1027,19 @@ struct iommu_group *iommu_group_get_for_dev(struct device *dev)*IOMMUdriver.*/if(!group->default_domain){-group->default_domain=-__iommu_domain_alloc(dev->bus,iommu_def_domain_type);+structiommu_domain*dom;++dom=__iommu_domain_alloc(dev->bus,iommu_def_domain_type);+if(!dom){+dev_warn(dev,+"failed to allocate default IOMMU domain of type %u; falling back to IOMMU_DOMAIN_DMA",+iommu_def_domain_type);
Conversely, that's going to be noisy if iommu_def_domain_type was
IOMMU_DOMAIN_DMA to begin with. I think it makes sense to warn if the
user asked for a specific default domain type on the command line and
that didn't work, but maybe not to bother otherwise. Plus, if they asked
for passthrough, then not allocating a default domain at all is probably
closer to the desired result than installing a DMA ops domain would be.
You're right -- I'll hack this about to check if the default type isn't
DOMAIN_DMA before warning about the allocation failure.
if some master devices want 'IDENTITY_DOMAIN' as default (because
those devices do not want any iommu resources to be used/dma_ops to be
set) and some 'DMA_DOMAIN' as default, then should the default be
'DMA_DOMAIN' and then masters needing IDENTITY_DOMAIN explicitly do an
detach_dev later. This [1] was adding the support for detach_dev
of the default DMA_DOMAINs.
[1] https://patchwork.codeaurora.org/patch/164933/
Regards,
Sricharan