On 27/01/2022 07:49, Penny Zheng wrote:
From: Stefano Stabellini <sstabell...@kernel.org>

When IOMMU is absent or shall not be used (trusted domain, performance,
hardware limitation, ..., etc), in which cases this commit avoids setting
XEN_DOMCTL_CDF_iommu to make those user cases possible and prevent failure
later during device assignment.
How about:

xen/arm: Allow device-passthrough even the IOMMU is off

At the moment, we are only supporting device-passthrough when Xen has enabled the IOMMU. There are some uses cases where it is not possible to use the IOMMU (e.g. doesn't exist, hardware limitation, performance) yet it would be OK to assign a device to trusted domain so long they are are direct-mapped or the device doesn't do DMA.

Note that when the IOMMU is disabled, it will be necessary to add xen,force-assign-without-iommu for every device that needs to be assigned.


Signed-off-by: Stefano Stabellini <stefano.stabell...@xilinx.com>
Signed-off-by: Penny Zheng <penny.zh...@arm.com>
Tested-by: Stefano Stabellini <sstabell...@kernel.org>
---
v3 changes:
- new commit, split from the original "[PATCH v2 2/6] xen/arm: introduce
direct-map for domUs"
---
v4 changes:
- explain briefly in the commit message why we want to do device assignment
without IOMMU.
---
v5 changes:
- nothing changed
---
  xen/arch/arm/domain_build.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 6467e8ee32..c1e8c99f64 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -3047,7 +3047,8 @@ void __init create_domUs(void)
              panic("Missing property 'cpus' for domain %s\n",
                    dt_node_name(node));
- if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") )
+        if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") &&
+             iommu_enabled )
              d_cfg.flags |= XEN_DOMCTL_CDF_iommu;
if ( !dt_property_read_u32(node, "nr_spis", &d_cfg.arch.nr_spis) )

Cheers,

--
Julien Grall

Reply via email to