search for: iommu_domain_dma

...group); +static int iommu_alloc_default_domain(struct device *dev, + struct iommu_group *group) +{ + struct iommu_domain *dom; + + if (group->default_domain) + return 0; + + dom = __iommu_domain_alloc(dev->bus, iommu_def_domain_type); + if (!dom && iommu_def_domain_type != IOMMU_DOMAIN_DMA) { + dom = __iommu_domain_alloc(dev->bus, IOMMU_DOMAIN_DMA); + if (dom) { + dev_warn(dev, + "failed to allocate default IOMMU domain of type %u; falling back to IOMMU_DOMAIN_DMA", + iommu_def_domain_type); + } + } + + if (!dom) + return -ENOMEM; + + group->default_doma...

...group); +static int iommu_alloc_default_domain(struct device *dev, + struct iommu_group *group) +{ + struct iommu_domain *dom; + + if (group->default_domain) + return 0; + + dom = __iommu_domain_alloc(dev->bus, iommu_def_domain_type); + if (!dom && iommu_def_domain_type != IOMMU_DOMAIN_DMA) { + dom = __iommu_domain_alloc(dev->bus, IOMMU_DOMAIN_DMA); + if (dom) { + dev_warn(dev, + "failed to allocate default IOMMU domain of type %u; falling back to IOMMU_DOMAIN_DMA", + iommu_def_domain_type); + } + } + + if (!dom) + return -ENOMEM; + + group->default_doma...

...group, + unsigned int type) { struct iommu_domain *dom; - unsigned int type; - - if (group->default_domain) - return 0; - type = iommu_get_def_domain_type(dev); - - dom = __iommu_domain_alloc(dev->bus, type); + dom = __iommu_domain_alloc(bus, type); if (!dom && type != IOMMU_DOMAIN_DMA) { - dom = __iommu_domain_alloc(dev->bus, IOMMU_DOMAIN_DMA); - if (dom) { - dev_warn(dev, - "failed to allocate default IOMMU domain of type %u; falling back to IOMMU_DOMAIN_DMA", - type); - } + dom = __iommu_domain_alloc(bus, IOMMU_DOMAIN_DMA); + if (dom) + pr_warn(&q...

...3daa..8d72ea0fb843 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -1908,7 +1908,8 @@ static void domain_exit(struct dmar_domain *domain) domain_remove_dev_info(domain); /* destroy iovas */ - put_iova_domain(&domain->iovad); + if (domain->domain.type == IOMMU_DOMAIN_DMA) + put_iova_domain(&domain->iovad); if (domain->pgd) { struct page *freelist; @@ -2671,19 +2672,9 @@ static struct dmar_domain *set_domain_for_dev(struct device *dev, } static int iommu_domain_identity_map(struct dmar_domain *domain, - unsigned long long start, -...

Hi, here is the second version of this patch-set. The first version with some more introductory text can be found here: https://lore.kernel.org/lkml/20200407183742.4344-1-joro at 8bytes.org/ Changes v1->v2: * Rebased to v5.7-rc1 * Re-wrote the arm-smmu changes as suggested by Robin Murphy * Re-worked the Exynos patches to hopefully not break the driver anymore * Fixed a missing

Hi, here is the second version of this patch-set. The first version with some more introductory text can be found here: https://lore.kernel.org/lkml/20200407183742.4344-1-joro at 8bytes.org/ Changes v1->v2: * Rebased to v5.7-rc1 * Re-wrote the arm-smmu changes as suggested by Robin Murphy * Re-worked the Exynos patches to hopefully not break the driver anymore * Fixed a missing

Hi, here is the third version of this patch-set. Older versions can be found here: v1: https://lore.kernel.org/lkml/20200407183742.4344-1-joro at 8bytes.org/ (Has some more introductory text) v2: https://lore.kernel.org/lkml/20200414131542.25608-1-joro at 8bytes.org/ Changes v2 -> v3: * Rebased v5.7-rc3 * Added a missing iommu_group_put() as reported by Lu Baolu. * Added a

...dev->archdata.iommu = DEFER_DEVICE_DOMAIN_INFO; - group = iommu_group_get_for_dev(dev); - - if (IS_ERR(group)) { - ret = PTR_ERR(group); - goto unlink; - } - - iommu_group_put(group); - - domain = iommu_get_domain_for_dev(dev); - dmar_domain = to_dmar_domain(domain); - if (domain->type == IOMMU_DOMAIN_DMA) { - if (device_def_domain_type(dev) == IOMMU_DOMAIN_IDENTITY) { - ret = iommu_request_dm_for_dev(dev); - if (ret) { - dmar_remove_one_dev_info(dev); - dmar_domain->flags |= DOMAIN_FLAG_LOSE_CHILDREN; - domain_add_dev_info(si_domain, dev); - dev_info(dev, - "Device use...

Hi, here is a patch-set to remove all calls of iommu_group_get_for_dev() from the IOMMU drivers and move the per-device group setup and default domain allocation into the IOMMU core code. This eliminates some ugly back and forth between IOMMU core code and the IOMMU drivers, where the driver called iommu_group_get_for_dev() which itself called back into the driver. The patch-set started as a

Hi, here is a patch-set to remove all calls of iommu_group_get_for_dev() from the IOMMU drivers and move the per-device group setup and default domain allocation into the IOMMU core code. This eliminates some ugly back and forth between IOMMU core code and the IOMMU drivers, where the driver called iommu_group_get_for_dev() which itself called back into the driver. The patch-set started as a

...Beware of "iommu.passthrough=1" - you could get a valid default domain here >> yet still have direct/SWIOTLB DMA ops. I guess you probably want to >> double-check the domain type as well. > > Good point. An earlier version of this patch had an additional check for > IOMMU_DOMAIN_DMA, but then that failed on 32-bit ARM because there the > DMA API can also use IOMMU_DOMAIN_UNMANAGED type domains. Checking for > IOMMU_DOMAIN_IDENTIFY should be safe, though. That doesn't seem to > appear in arch/arm, arch/arm64 or drivers/iommu/dma-iommu.c. Right, "domain &&...

...s things nicer overall and shouldn't have any performance impact. [...] >>> +static struct iommu_domain *viommu_domain_alloc(unsigned type) >>> +{ >>> + struct viommu_domain *vdomain; >>> + >>> + if (type != IOMMU_DOMAIN_UNMANAGED && type != IOMMU_DOMAIN_DMA) >> smmu drivers also support the IDENTITY type. Don't we want to support it >> as well? > > Eventually yes. The IDENTITY domain is useful when an IOMMU has been > forced upon you and gets in the way of performance, in which case you > get rid of it with CONFIG_IOMMU_DE...

Hi Thierry, On 16/09/2019 16:04, Thierry Reding wrote: > From: Thierry Reding <treding at nvidia.com> > > If the GPU is already attached to an IOMMU, don't detach it and setup an > explicit IOMMU domain. Since Nouveau can now properly handle the case of > the DMA API being backed by an IOMMU, just continue using the DMA API. > > Signed-off-by: Thierry Reding

This patchset converts the intel iommu driver to the dma-iommu api. While converting the driver I exposed a bug in the intel i915 driver which causes a huge amount of artifacts on the screen of my laptop. You can see a picture of it here: https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg This issue is most likely in the i915 driver and is most likely caused by the

This patchset converts the intel iommu driver to the dma-iommu api. While converting the driver I exposed a bug in the intel i915 driver which causes a huge amount of artifacts on the screen of my laptop. You can see a picture of it here: https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg This issue is most likely in the i915 driver and is most likely caused by the

...); >> + >> + return ret; >> +} >> + >> +/* IOMMU API */ >> + >> +static struct iommu_domain *viommu_domain_alloc(unsigned type) >> +{ >> + struct viommu_domain *vdomain; >> + >> + if (type != IOMMU_DOMAIN_UNMANAGED && type != IOMMU_DOMAIN_DMA) > smmu drivers also support the IDENTITY type. Don't we want to support it > as well? Eventually yes. The IDENTITY domain is useful when an IOMMU has been forced upon you and gets in the way of performance, in which case you get rid of it with CONFIG_IOMMU_DEFAULT_PASSTHROUGH=y or iommu...

...estore(&vdomain->mappings_lock, flags); > + > + return ret; > +} > + > +/* IOMMU API */ > + > +static struct iommu_domain *viommu_domain_alloc(unsigned type) > +{ > + struct viommu_domain *vdomain; > + > + if (type != IOMMU_DOMAIN_UNMANAGED && type != IOMMU_DOMAIN_DMA) smmu drivers also support the IDENTITY type. Don't we want to support it as well? > + return NULL; > + > + vdomain = kzalloc(sizeof(*vdomain), GFP_KERNEL); > + if (!vdomain) > + return NULL; > + > + mutex_init(&vdomain->mutex); > + spin_lock_init(&vdomain-&...

...estore(&vdomain->mappings_lock, flags); > + > + return ret; > +} > + > +/* IOMMU API */ > + > +static struct iommu_domain *viommu_domain_alloc(unsigned type) > +{ > + struct viommu_domain *vdomain; > + > + if (type != IOMMU_DOMAIN_UNMANAGED && type != IOMMU_DOMAIN_DMA) smmu drivers also support the IDENTITY type. Don't we want to support it as well? > + return NULL; > + > + vdomain = kzalloc(sizeof(*vdomain), GFP_KERNEL); > + if (!vdomain) > + return NULL; > + > + mutex_init(&vdomain->mutex); > + spin_lock_init(&vdomain-&...

...; + return; > > Beware of "iommu.passthrough=1" - you could get a valid default domain here > yet still have direct/SWIOTLB DMA ops. I guess you probably want to > double-check the domain type as well. Good point. An earlier version of this patch had an additional check for IOMMU_DOMAIN_DMA, but then that failed on 32-bit ARM because there the DMA API can also use IOMMU_DOMAIN_UNMANAGED type domains. Checking for IOMMU_DOMAIN_IDENTIFY should be safe, though. That doesn't seem to appear in arch/arm, arch/arm64 or drivers/iommu/dma-iommu.c. Thierry -------------- next part --------...

...dev(struct device *dev, unsigned long type) iommu_domain_free(group->default_domain); group->default_domain = domain; - iommu_group_create_direct_mappings(group, dev); + iommu_create_device_direct_mappings(group, dev); dev_info(dev, "Using iommu %s mapping\n", type == IOMMU_DOMAIN_DMA ? "dma" : "direct"); -- 2.17.1